gulp + webpack 构建多页面前端项目
gulp + webpack 构建多页面前端项目
修改增加了demo地址 gulp-webpack-demo
之前在使用gulp和webpack对项目进行构建的时候遇到了一些问题，最终算是搭建了一套比较完整的解决方案，接下来这篇文章以一个实际项目为例子，讲解多页面项目中如何利用gulp和webpack进行工程化构建。本文是自己的实践经验，所以有些解决方案并不是最优的，仍在探索优化中。所以有什么错误疏漏请随时指出。
使用gulp过程中的一些问题，我已经在另外一篇文章讲到了 grunt or gulp
前言
现在为什么又整了一个webpack进来呢？
我们知道webpack近来都比较火，那他火的原因是什么，有什么特别屌的功能吗？带着这些疑问，继续看下去。
在使用gulp进行项目构建的时候，我们一开始的策略是将所有js打包为一个文件，所有css打包为一个文件。然后每个页面都将只加载一个js和一个css,也就是我们通常所说的 ==all in one== 打包模式。这样做的目的就是减少http请求。这个方案对于简单的前端项目来说的是一个万金油。因为通常页面依赖的js,css并不会太大，通过压缩和gzip等方法更加减小了文件的体积。在项目最开始的一段时间内（几个月甚至更长），一个前端团队都能通过这种办法达到以不变应万变的效果。
然而，作为一个有追求（爱折腾）的前端，难道就满足于此吗？
妈妈说我不仅要请求合并，还要按需加载，我要模块化开发，还要自动监听文件更新，支持图片自动合并....
等等！你真的需要这些功能吗？是项目真的遇到了性能问题？不然你整这些干嘛？
对于pc端应用来说，性能往往不是最突出的问题，因为pc端的网速，浏览器性能都有比较好，所以很长一段时间我们要考虑的是开发效率的问题而不是性能问题，得在前端框架的选型上下功夫。至于加载文件的大小或文件个数，都难以形成性能瓶颈。
对于wap端来说，限制于手机的慢网速（仍然有很多用不上4g，wifi的人），对网站的性能要求就比较苛刻了，这时候就不仅仅要考虑开发效率的问题了。（移动网络的性能问题可参考《web性能权威指南》）
在《高性能网站建设进阶指南》中也讲到：不要过早地考虑网站的性能问题。
这点我有不一样的看法。如果我们在项目搭建的时候就能考虑得多一点，把基本能做的先做了。所花的成本绝对比以后去重构代码的成本要低很多，而且我们能够同时保证开发效率和网站性能，何乐而不为呢。
问题
竟然要做，那要做到什么程度呢，往往“度”是最难把握的东西。
以前在做wap网站的时候，遇到的最大的问题按需加载和请求合并的权衡。
通过纯前端的方法不能同时满足请求合并和按需加载，这里面的原理和难点已经有大牛讲得很清楚了 前端工程与模块化框架
实现的方法归纳起来主要有以下步骤：
-
通过工具分析出前端静态文件依赖表
-
页面通过模块化工具加载入口文件，并将所依赖的所有文件合并为combo请求。
-
后端返回combo文件，浏览器将模块缓存起来，跳页面的时候执行步骤2，只请求没有缓存过的文件。
如此通过依赖分析和后端combo实现了按需加载和请求合并。
这种实现方式的缺陷就是需要后端的支持，如果前端团队本身不是自己实现的后端路由层，需要后端同学加以配合，就需要更多沟通成本。
在没有后端支持的情况下，很难实现按需加载和请求合并。
针对这个问题webpack有没有什么解决方案？而webpack和gulp又是怎么协作的呢？请看下去。
webpack的使用
webpack可以说是一个大而全的前端构建工具。它实现了模块化开发和静态文件处理两大问题。
以往我们要在项目中支持模块化开发，需要引入requirejs，seajs等模块加载框架。而webpack天生支持AMD，CommonJS, ES6 module等模块规范。不用思考加载器的选型，可以直接像写nodejs一样写模块。
而webpack这种万物皆模块的思想好像就是为React而生的，在React组件中可以直接引入css或图片，而做到这一切只需要一个require语句和loader的配置。
webpack的功能之多和繁杂的配置项会让初学者感到眼花缭乱，网上的很多资料也是只介绍功能不教人实用技巧。这里有一篇文章就讲解了webpack开发的workflow, 虽然该教程是基于React的，但是比较完整地讲了webpack的开发流程。下面我也用一个实例讲解使用中遇到的问题和解决方案。
我们的项目是一个多页面项目，即每个页面为一个html，访问不同的页面需要跳转链接。
项目目录结构大概是这样的，app放html文件，css为样式文件，images存放图片，js下有不同的文件夹，里面的子文件夹为一些核心文件和一些库文件，ui组件。js的根目录为页面入口文件。
├── app
│ ├── header.inc
│ ├── help-charge.inc
│ ├── index.html
│ ├── news-detail.html
│ └── news-list.html
├── css
│ ├── icon.less
│ └── slider.css
├── images
└── js
├── core
├── lib
├── ui
├── news-detail.js
├── news-list.js
└── main.js该项目中我们只用webpack处理js文件的合并压缩。其他任务交给gulp。关于多页面项目和单页面项目中js处理的差异请看这里。
配置文件如下：
module.exports = {
devtool: "source-map", //生成sourcemap,便于开发调试
entry: getEntry(), //获取项目入口js文件
output: {
path: path.join(__dirname, "dist/js/"), //文件输出目录 publicPath: "dist/js/", //用于配置文件发布路径，如CDN或本地服务器 filename: "[name].js", //根据入口文件输出的对应多个文件名 }, module: { //各种加载器，即让各种文件格式可用require引用 loaders: [ // { test: /\.css$/, loader: "style-loader!css-loader"}, // { test: /\.less$/, loader: "style-loader!csss-loader!less-loader"} ] }, resolve: { //配置别名，在项目中可缩减引用路径 alias: { jquery: srcDir + "/js/lib/jquery.min.js", core: srcDir + "/js/core", ui: srcDir + "/js/ui" } }, plugins: [ //提供全局的变量，在模块中使用无需用require引入 new webpack.ProvidePlugin({ jQuery: "jquery", $: "jquery", // nie: "nie" }), //将公共代码抽离出来合并为一个文件 new CommonsChunkPlugin('common.js'), //js文件的压缩 new uglifyJsPlugin({ compress: { warnings: false } }) ] };配置项参考文档
打包思路：
该配置方案的思路是每个页面一个入口文件，文件中可以通过require引入其他模块，而这些模块webpack会自动跟入口文件合并为一个文件。通过getEntry获取入口文件：
function getEntry() {
var jsPath = path.resolve(srcDir, 'js'); var dirs = fs.readdirSync(jsPath); var matchs = [], files = {}; dirs.forEach(function (item) { matchs = item.match(/(.+)\.js$/); if (matchs) { files[matchs[1]] = path.resolve(srcDir, 'js', item); } }); return files; }该方法将生成文件名到文件绝对路径的map， 比如
entry：{
news-detail: /../Document/project/.../news-detail.js }然后output就会在output.path路径下生成[name].js，即news-detail.js,文件名保持相同。
module 的作用是添加loaders, 那loaders有什么作用呢？
如果我们想要在js文件中通过require引入模块，比如css或image，那么就需要在这里配置加载器，这一点对于React来说相当方便，因为可以在组件中使用模块化CSS。而一般的项目中可以不用到这个加载器。
resolve 中的alias可以用于定义别名，用过seajs等模块工具的都知道alias的作用，比如我们在这里定义了ui这个别名，那么在模块中想引用ui目录下的文件，就可以直接这样写
require('ui/dialog.js');不用加上前面的更长的文件路径。
plugin 用于引入一些插件，常见的有 这些
我们这里使用了CommonsChunkPlugin用于生成公用代码，不只可以生成一个，还能根据不同页面的文件关系，自由生成多个，例如：
var CommonsChunkPlugin = require("webpack/lib/optimize/CommonsChunkPlugin");
module.exports = {
entry: {
p1: "./page1", p2: "./page2", p3: "./page3", ap1: "./admin/page1", ap2: "./admin/page2" }, output: { filename: "[name].js" }, plugins: [ new CommonsChunkPlugin("admin-commons.js", ["ap1", "ap2"]), new CommonsChunkPlugin("commons.js", ["p1", "p2", "admin-commons.js"]) ] }; // 在不同页面用