webpack搭建前端一条龙服务

作为从grunt、gulp一路走来的老码农，一开始用webpack的时候我是很抗拒的。但由于核心库使用了vue，而webpack又是vue的最佳拍档（vue作者专门为其写了vue-loader），所以用webpack来构建项目就成了自然而然的事情。经过一段时间的摸索，各个流程都跑通了，「从入门到放弃」的那点事也就都不算事了。

webpack是以模块为中心的打包工具，但由于其日渐丰富的插件，能做的事情已经很多了，从开发环境搭建到上线构建，几乎可以一条龙包办了。事实上我在最近的项目中，连gulp都省了，完全用webpack就完成了所有的工作。下面一一道来。

本地server

在前后端分离的大前提下，前端本地已不需要起后端服务了，那为什么还要起一个本地server呢？这个server主要提供以下支持：

1. 静态资源访问

2. 代码热更新（实时刷新浏览器）

3. 模拟请求数据

4. 代理http请求

本地server是由webpack插件webpack-dev-middleware提供的，它是基于express的，所以还需要把express也装上。配置代码相当简单：

var devMiddleware = require('webpack-dev-middleware')(compiler, {
    publicPath: config.output.publicPath,
    stats: {
        colors: true,
        chunks: false
    }
});

app.use(devMiddleware);

通常我们把它保存为dev-server.js，然后配合npm script来启动这个server，在package.json中写好：

"scripts": {
    "dev": "node ./build/dev-server.js"
}

然后一行命令就可以启动了：npm run dev

需要注意的一点事，当我们起了本地server之后，webpack打包后的文件并不写入到硬盘上，而是保存在内存中。所以你并不会在目录下看到生成的文件，但是浏览器已经能够按照路径进行访问了，这样开发环境下的编译速度就大大加快。

独立vue组件

用了webpack之后，写vue组件最爽的就是可以写成单独的.vue文件了，在一个文件中写好所有的样式、模板、js逻辑。然后vue-loader就会帮我们编译成标准的vue组件。

令人高兴的是，vue2.0引入了虚拟DOM来提高性能，vue-loader也会将我们的模板编译成虚拟DOM来使用，你也不必费劲再去写render函数了。

编译ES6

之前也说过项目已经完全用ES6了，所以我们在开发环境需要用babel进行编译，我们写ES6代码的地方有两个，一个是js文件，另一个是.vue文件中的。

js文件的在webpack配置文件中配置loader即可：

{
    test: /.js$/,
    loader: 'babel',
    exclude: /node_modules/
}

而.vue文件中的，vue-loader已经天然帮我们做了，所以不需要任何设置。

babel的配置项，写在.babelrc中放在根目录下即可。

编译sass

前端进入编译时代，css当然也是少不了的。项目中使用了sass来编写css代码，所以也需要在开发环境进行编译。需要编译的有两个地方，一个是外链的.scss文件，另一个是.vue文件中的。

对于.scss文件，我们还是用loader来处理，安装sass-loader，然后在webpack配置文件中配好：

{
    test: /.scss$/,
    loader: ExtractTextPlugin.extract('style', 'css!sass')
}

至于.vue文件中的，vue-loader早帮我们做好了工作，只需在<style>标签加上lang属性就可以了，例如编译sass

<style lang="sass">
/*此处可以写sass代码啦*/

</style>

代码检查

在开发阶段进行代码检查也是一项必要工作，检查ES6当然eslint是标配，在配置文件中可以通过preLoaders来配置：

preLoaders: [
{
    test: /.(js|vue)$/,
    exclude: /node_modules/,
    loader: 'eslint-loader'
}
]

这样在js文件和.vue文件中的代码都会用eslint规则进行检查。eslint的配置同样写在.eslintrc文件中放在根目录下。

代码热更新

编译工作就是以上这些了。当我们开始正式敲代码之后，还有一个功能是梦寐以求的，那就是代码热更新。即编辑器保存代码后，浏览器实时刷新。这个特性在webpack中叫做”模块热替换(hot module repacement)“，使用webpack-hot-middleware这个插件来完成。

这个插件跟我们以前用的live-reload不同，它不会刷新浏览器页面，而是把模块进行热替换。这样的好处是，应用的当前状态还能保持，但是代码已经更新了。比以前爽了不止一点半点。

模拟数据

前后端分离开发中，还有重要的一环，就是前端mock数据。在后端接口开发完成之前，我们可以通过自己模拟的数据完成调试。

事实上mock数据并不需要webpack提供，而是通过我们的本地server，写express中间件的方式。需要以下两步：

第一步，根目录下建一个mock目录，用于放置假数据，每个接口一个js文件，为了便于express使用，文件的格式如下：

module.exports = {
    api: '/api/mock/banner',
    response: function (req, res) {
        res.json({
            success: true,
            data: {
                name: 'test'
            }
        });
    }
}

第二步，在dev-server中把mock的数据挂载到express上，代码如下：

var mockDir = path.resolve(__dirname, '../mock');
    fs.readdirSync(mockDir).forEach(function (file) {
    var mock = require(path.resolve(mockDir, file));
    app.use(mock.api, mock.response);
});

这样当我们请求的路径中含有/api/mock字样时，就会返回我们mock的数据啦。当后端的接口开发完成时，我们就可以把路径中的mock去掉，从而去请求后端的接口。

代理请求

由于我们起了本地server，ajax路径是相对的，所以请求会打到本地的这个server上。当我们需要调试后端接口时，就得把请求转发到后端服务器。为了避免跨域的麻烦，通常需要配置http代理。

我使用了http-proxy-middleware这个中间件，这也是和webpack无关的，它也是一个express中间件。配置方法如下：

app.use(proxy('/api', {
    target: {
        host: 'localhost',
        protocol: 'http:',
        port: 5050
    },
    logLevel: 'debug'
}));

我们和后端协商好，所有异步请求都带"/api"前缀，这样我就把请求转发到后端服务器了。此处我把host填了localhost，意味着我本地起了一个后端服务，事实上可以指向任何一台可以提供接口的服务器。

这个proxy中间件有一个小坑，就是路径必须向我这样分开写。如果拼在一起不会生效，我目前没找到原因。

移动端远程调试

出于平台兼容性的考虑，移动端调试我选择了weinre。用过weinre的同学应该知道，我们需要在页面上嵌一个<script>标签才能使用weinre。不熟悉的同学可以参考我之前写的这篇：http://www.cnblogs.com/lvdabao/p/3436620.html

所以，我们需要对当前运行的环境进行判断，如果是开发环境才嵌入这个标签。我用了一个叫做DefinePlugin的插件来在通过webpack在页面全局定义变量，用法如下：

new webpack.DefinePlugin({
    LOCAL_IP: JSON.stringify(localIP),
    __ENV__: JSON.stringify('dev'),
    WEINRE_RUN: JSON.stringify(process.argv[2]=='weinre')
})

这样，在页面初始化的时候，我们就可以根据当前的环境来决定是否嵌入这个<script>啦，如下：

if(__ENV__ == 'dev' && WEINRE_RUN){
    document.write('<script src="http://'+LOCAL_IP+':8080/target/target-script-min.js#anonymous"></script>');
}

插入<script>标签

我们的js打包好后，下一步就是把它引入到html文件了。由于我们通常会用md5作为文件名来控制js版本，所以html中的文件地址就需要每次构建后进行更新。

webpack中是通过HtmlWebpackPlugin这个插件来实现的，它的特点在于，每次构建基于一个html模板来生成新的html文件，所以并不是替换js路径。在webpack的plugins选项中如下配置：

new HtmlWebpackPlugin({
    filename: path.resolve(__dirname, '../static/dist/index.html'),
    chunks: ['vendor', 'components', 'app'],
    template: path.resolve(__dirname, '../static/src/index.html'),
    inject: true
})

代码压缩

在gulp时代，我们是通过配置gulp任务来完成js的压缩。在webpack中，是通过插件来完成的，相同的道理，在plugins中进行如下配置：

new webpack.optimize.UglifyJsPlugin({
    compress: {
        warnings: false
    }
})

另外，webpack可以进行sourcemap配置，用于帮助映射文件，开启代码如下：devtool: 'source-map'

打包结果分析

在打包完成之后，我们经常会有这个心理：生成的文件完全不可读，打包的结果到底对不对，有没有重复打包，有没有冗余的东西。

这个时候就需要一个分析工具了，webpack有这样一个插件，能以可视化的方式展示打包结果，为你提供分析需求。它就是BundleAnalyzerPlugin，相当好用，我上一张我的截图：

上线构建

以上大部分是开发环境需要的配置，当我们本地测试完毕需要上线时，就需要真正生成文件了。

我们一般会准备两个或者多个（如何有多个环境，如test环境）webpack配置文件，用于不同的环境。在线上服务器跑的配置文件我们一般会修改输出地址，如果需要配cdn的话，把output中的publicPath填成cdn地址即可。然后直接运行webpack编译命令，而不是像本地server那样起。

同样我们也会写一个npm script，像这样：

"scripts": {
    "dev": "node ./build/dev-server.js",
    "build": "webpack --config ./build/prod.webpack.config.js"
}

我对webpack的应用大概就是这么多了，本想大致介绍，没想到一贴就是这么多代码~~其实webpack的精髓我本篇并未提及，那就是打包策略的选择，不同的项目架构需要不同的打包方式，而这个过程，则充满了挑战，你懂的。

（本文始发于我的微信公众号(doctor-programmer)，整理重新编辑后发于博客，有兴趣的同学欢迎关注我的公众号，右边扫码去吧~）