前端工程化这些事情现在已经算是深入人心了，即便不清楚具体含义vue-cli creat-react-app之类的脚手架也帮助大家快速开发了不少项目。

今天顺便总结了下之前的一些经验，希望对大家的工作或者学习有一些帮助。
老生常谈的splitChunks、Dll啥的就不多说了，简单分享些插件和配置功能优化，方便大家更省力地写代码。

配置

1. 代理配置：

很多时候我们为了跨域会给devServer配个proxy啥的，没数据的时候要连接到mock接口上，有数据的时候又要切换到dev上，有时候又要调试复现qa环境的问题，一般像这个时候我们可以简单配个npm script

# 默认 dev 环境
    npm run dev

    # mock 环境
    npm run dev --mock

那对webpack怎么配置呢

新建一个proxy.js文件

const config = {
    dev: {
         ... // 你的proxy配置 文档自行参考 https://webpack.js.org/configuration/dev-server/#devserver-proxy  
    },
    mock: {
        ...
    }
};

let proxy = config.dev;

for (const key in proxy) {
    if (process.env[`npm_config_${key}`]) {
        current = { ...proxy, ...config[key] };
    };
};
module.exports = current;

然后导入到你的webpack.config.dev.js中，设置为devServer的proxy

const proxy = require('./proxy.js');

...
devServer: {
    ...
    proxy: proxy
}

然后就完事了，当然了，这是最简单的方式，一般情况下我们是还需要根据当前运行的环境变量再做判定的。业务上的问题这里就不展开了。

2. log信息

很多时候我们会在项目运行或者打包的时候出现一大堆没啥用的信息，
改下webpack里的stats即可
开发环境也可以用friendly-errors-webpack-plugin也是挺方便的

3.sourceMap

开发环境随便配个喜欢的sourceMap就好，但是生产环境就要去掉了，当然为了方便qa调试，最好也为打包做好各种环境设置，
但是别把sourcemap打到业务代码里是每个程序员的基本素养。对，我说的就是inline-source-map这种配置，有的话赶紧改掉，相信我这是为了你的职业生涯考虑。生产环境要用也只能用source-map,然后让运维大哥随手屏蔽下所有.map文件即可。

功能插件

1. 依赖分析

这个是之前在vue-cli上找的，用着感觉也挺顺手的，

# 下载插件
npm i -D webpack-bundle-analyzer

// 注入webpack.config.prod.js
    const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
    
    // 写入plugin     
    ...
    plugins: [
        process.env.npm_config_report && new BundleAnalyzerPlugin()
    ]

然后你就可以在打完包后来一个依赖分析,用着也挺方便的

npm run build --report

2. 邮件

有些利用travis 或者jenkins做远端打包的项目，在项目发布前可以简单配置一个邮件功能，包含打包内容、git commit信息什么的， 就不需要专门找人一一告知，方便所有开发人员根据业务，提高开发效率。
推荐nodemailer

工作流程优化

Makefile

很多时候npm script 可能不够用或者说看上去并不怎么直观，因为没法写备注可能也说不清具体什么用
这时候可以使用Makefile
在根目录建个Makefile文件
然后就可以在里面配置一些基本命令，可以理解为对npm script做一个简单的封装，关键是可以写备注

# 开发
start:
    npm run dev

# 打包
build:
    npm run build

# mock环境
mock:
    npm run dev --mock

然后你在当前目录下输入

make start

就可以开始干活了

异常追踪

线上环境为了保证用户隐私是不允许开发人员直接接触用户信息的，但是有些问题光靠公司现有的测试机也无法完全覆盖，异常跟踪的框架网上挺多，这里简单提一下不做深入讨论。

开源常用的是sentry，具体怎么用自己看，弄个docker镜像跑一下啥的还是挺方便的。
收费的市面上不少，就不打广告了。

其他环境

如果业务中涉及到一些server端的开发的话肯定要解决各类服务端软件的安装比如Redis，MySql MongoDB等，而不同项目可能还需要不同版本的数据库，甚至还可能要考虑node的版本，而各种版本的切换是一个让人头疼的事情，甚至因为某些原因还要两个版本同时运行在一台机器上，那怎么办呢？
于是我们开始考虑引入使用docker

Docker

Docker的基本使用就是简单的找个镜像 install 然后 run 就行了，
-v挂上持久化， -p 挂上端口

# 例 ：redis
    $ docker run -d -p 6379:6379 redis

类似这样就能直接在机器上挂上最新的redis镜像并映射到本地6379端口，简单粗暴，再挂下持久化啥的丢到 Makefile 里直接运行就行了，用的人也不需要费时费力地去装redis
同理如果对node也有要求的话

docker run -t -i -p 8000:8000 -w /project -v $PWD:/project node:11.3.0 /bin/bash

直接运行上面这行命令就可以直接在 docker 中直接运行打开bash输入框运行 node 环境进行开发了，这样即使用户机器上没有 node 也照样可以开发 node 程序，不过以上只是直接创建了同名镜像，容易被其他项目覆盖，真实环境别直接这样做，出问题了我可不负责的啊。而且性能啥的也不是特别好。
有必要的话还是建议学习下 docker 能帮你解决不少事。
另外， Docker 的正规操作常用于服务端项目的发布，增加了不少灵活性，一下子解放了运维大哥。
当然以上的介绍连冰山一角都不到，我也是正在学习Docker。

待续