1. 前端构建工具webpack有什么缺陷
1.文档缺失，尤其中文文档
长期以来webpack官方文档和example匮乏，提供的一些例子都是很简单那种，经常发现完全按照例子来配置但就是跑不起来，中文文档就更不用说了，少的可怜。这个问题也直接导致下面的第2点。
2.配置难&难调试
稍微复杂一点的项目，如果使用webpack编译，不经过一段痛苦不堪的配置调试过程是没法正常跑起来的。这还没完，在自己机器上跑起来之后可能到了另一个同事哪儿又报错了等等。总之正如下面有人回答那样，配置文件一旦跑起来，是根本不敢去改的，生怕又出错。
webpack的错误提示也非常难看懂，基本不可能从错误很直观的找到原因，长期以来碰到问题只能靠猜，你没看错，就是靠猜！！
3.编译慢
经验不足的同学很容易碰到这个问题，当然可以通过一些手段做优化，比如配置mole的resolve、root等，使用happypack加速、dll提前编译等等。但是笔者曾经尝试过happypack，对编译速度有提升但效果不明显，dll的话我有按照官方文档的做法去做，但是最终编译出来又报了一些莫名其妙的错（也有可能是代码写的有问题），总之心累，后来直接改成externals方式，全局script引入第三方库。
4.对server-render不友好
webpack本质上还是静态打包，意思就是打包完成之后其实文件的加载顺序已经固定，只是被加载的时间不定而已。所以使用webpack原则上不存在按需加载之类的说法，code split其实是人工分隔，但是真实的按需加载场景岂是人工能枚举完的 （下划线这句话不太好解释，也不想过多解释，熟悉前端工程的人应该都明白啥意思）。
在这里我要说的对server-render不友好其实是指html的处理，webpack其实是通过在js里用require标记资源然后加载任意资源（css、图片、fonts等等），但其实html文件才是页面真实的入口，最终编译出的js还是需要引入到html里，为了防止css懒加载导致页面抖动，编译完的css还需要从js里边提取出来放到html外链。
目前一般都是通过html-webpack-plugin来做这个事情，先搜集某个html所引用的静态资源最终自动插入到html。这种方式对于前端渲染的应用没有问题，但是对于server-render的那就不行了，因为server-render下html是作为模板由后端语言吐出，而开发模式下（例如webpack-dev-server）webpack是不会输出任何文件的（开发环境webpack是将文件放到内存然后在路由层自动serve了），所以这会导致开发环境模板无法引用静态资源。当然，有一种解决方案就是静态资源不改变文件名称，预先写好路径，开发环境和生产环境同名（即覆盖式发布）。
2. webpack执行机制流程是怎么样的
几乎所有业务的开发构建都会用到 webpack 。的确，作为模块加载和打包神器，只需配置几个文件，加载各种 loader 就可以享受无痛流程化开发。但对于 webpack 这样一个复杂度较高的插件集合，它的整体流程及思想对我们来说还是很透明的。那么接下来我会带你了解 webpack 这样一个构建黑盒，首先来谈谈它的流程。 准备工作 1. webstorm 中配置 webpack-webstorm-debugger-script 在开始了解之前，必须要能对 webpack 整个流程进行 debug ，配置过程比较简单。 先将 webpack-webstorm-debugger-script 中的软件外包企业公司 置于 webpack.config.js 的同一目录下，搭建好你的脚手架后就可以直接 Debug 这个 webstorm-debugger.js 文件了。 2. webpack.config.js 配置 估计大家对 webpack.config.js 的配置也尝试过不少次了，这里就大致对这个配置文件进行个分析。 var path = require('path'); var node_moles = path.resolve(__dirname, 'node_moles'); var pathToReact = path.resolve(node_moles, 'react/dist/react.min.js'); mole.exports = { // 入口文件，是模块构建的起点，同时每一个入口文件对应最后生成的一个 chunk。 entry: { bundle: [ 'webpack/hot/dev-server', 'webpack-dev-server/client?', path.resolve(__dirname, 'app/app.js') ], }, // 文件路径指向(可加快打包过程)。 resolve: { alias: { 'react': pathToReact } }, // 生成文件，是模块构建的终点，包括输出文件与输出路径。 output: { path: path.resolve(__dirname, 'build'), filename: '[name].js', }, // 这里配置了处理各模块的 loader ，包括 css 预处理 loader ，es6 编译 loader，图片处理 loader。 mole: { loaders: [ { test: /\.js$/, loader: 'babel', query: { presets: ['es2015', 'react'] } } ], noParse: [pathToReact] }, // webpack 各插件对象，在 webpack 的事件流中执行对应的方法。 plugins: [ new webpack.HotMoleReplacementPlugin(); ] }; 除此之外再大致介绍下 webpack 的一些核心概念: loader : 能转换各类资源，并处理成对应模块的加载器。loader 间可以串行使用。 chunk : code splitting后的产物，也就是按需加载的分块，装载了不同的mole。 对于mole和chunk的关系可以参照webpack官方的这张图: plugin : webpack 的插件实体，这里以 UglifyJsPlugin 为例。 function UglifyJsPlugin(options) { this.options = options; } mole.exports = UglifyJsPlugin; UglifyJsPlugin.prototype.apply = function(compiler) { compiler.plugin("compilation", function(compilation) { compilation.plugin("build-mole", function(mole) { }); compilation.plugin("optimize-chunk-assets", function(chunks, callback) { // Uglify 逻辑 }); compilation.plugin("normal-mole-loader", function(context) { }); }); }; 在 webpack 中你经常可以看到 compilation.plugin('xxx', callback) ，你可以把它当作是一个事件的绑定，这些事件在打包时由 webpack 来触发。 3. 流程总览 在具体流程学习前，可以先通过这幅 webpack整体流程图 了解一下大致流程(建议保存下来查看)。 shell 与 config 解析 每次在命令行输入 webpack 后，操作系统都会去调用 ./node_moles/.bin/webpack 这个 shell 脚本。这个脚本会去调用./node_moles/webpack/bin/webpack.js 并追加输入的参数，如 -p , -w 。(图中 webpack.js 是 webpack 的启动文件，而 $@ 是后缀参数) 在 webpack.js 这个文件中 webpack 通过 optimist 将用户配置的 webpack.config.js 和 shell 脚本传过来的参数整合成 options 对象传到了下一个流程的控制对象中。 1. optimist 和 commander 一样，optimist 实现了 node 命令行的解析，其 API 调用非常方便。 var optimist = require("optimist"); optimist .boolean("json").alias("json", "j").describe("json") .boolean("colors").alias("colors", "c").describe("colors") .boolean("watch").alias("watch", "w").describe("watch") ... 获取到后缀参数后，optimist 分析参数并以键值对的形式把参数对象保存在 optimist.argv 中，来看看 argv 究竟有什么？ // webpack --hot -w { hot: true, profile: false, watch: true, ... } 2. config 合并与插件加载 在加载插件之前，webpack 将 webpack.config.js 中的各个配置项拷贝到 options 对象中，并加载用户配置在 webpack.config.js 的 plugins 。接着 optimist.argv 会被传入到 ./node_moles/webpack/bin/convert-argv.js 中，通过判断 argv 中参数的值决定是否去加载对应插件。(至于 webpack 插件运行机制，在之后的运行机制篇会提到) ifBooleanArg("hot", function() { ensureArray(options, "plugins"); var HotMoleReplacementPlugin = require("../lib/HotMoleReplacementPlugin"); options.plugins.push(new HotMoleReplacementPlugin()); }); ... return options; options 作为最后返回结果，包含了之后构建阶段所需的重要信息。 { entry: {},//入口配置 output: {}, //输出配置 plugins: [], //插件集合(配置文件 + shell指令) mole: { loaders: [ [Object] ] }, //模块配置 context: //工程路径 ... } 这和 webpack.config.js 的配置非常相似，只是多了一些经 shell 传入的插件对象。插件对象一初始化完毕， options 也就传入到了下个流程中。 var webpack = require("../lib/webpack.js"); var compiler = webpack(options); 编译与构建流程 在加载配置文件和 shell 后缀参数申明的插件，并传入构建信息 options 对象后，开始整个 webpack 打包最漫长的一步。而这个时候，真正的 webpack 对象才刚被初始化，具体的初始化逻辑在 lib/webpack.js 中，如下: function webpack(options) { var compiler = new Compiler(); ...// 检查options,若watch字段为true,则开启watch线程 return compiler; } ... webpack 的实际入口是 Compiler 中的 run 方法，run 一旦执行后，就开始了编译和构建流程 ，其中有几个比较关键的 webpack 事件节点。 compile 开始编译 make 从入口点分析模块及其依赖的模块，创建这些模块对象 build-mole 构建模块 after-compile 完成构建 seal 封装构建结果 emit 把各个chunk输出到结果文件 after-emit 完成输出 1. 核心对象 Compilation compiler.run 后首先会触发 compile ，这一步会构建出 Compilation 对象: compilation类图 这个对象有两个作用，一是负责组织整个打包过程，包含了每个构建环节及输出环节所对应的方法，可以从图中看到比较关键的步骤，如 addEntry() , _addMoleChain() , buildMole() , seal() , createChunkAssets() (在每一个节点都会触发 webpack 事件去调用各插件)。二是该对象内部存放着所有 mole ，chunk，生成的 asset 以及用来生成最后打包文件的 template 的信息。 2. 编译与构建主流程 在创建 mole 之前，Compiler 会触发 make，并调用 Compilation.addEntry 方法，通过 options 对象的 entry 字段找到我们的入口js文件。之后，在 addEntry 中调用私有方法 _addMoleChain ，这个方法主要做了两件事情。一是根据模块的类型获取对应的模块工厂并创建模块，二是构建模块。 而构建模块作为最耗时的一步，又可细化为三步: 调用各 loader 处理模块之间的依赖 webpack 提供的一个很大的便利就是能将所有资源都整合成模块，不仅仅是 js 文件。所以需要一些 loader ，比如 url-loader ，jsx-loader ， css-loader 等等来让我们可以直接在源文件中引用各类资源。webpack 调用 doBuild() ，对每一个 require() 用对应的 loader 进行加工，最后生成一个 js mole。 Compilation.prototype._addMoleChain = function process(context, dependency, onMole, callback) { var start = this.profile && +new Date(); ... // 根据模块的类型获取对应的模块工厂并创建模块 var moleFactory = this.dependencyFactories.get(dependency.constructor); ... moleFactory.create(context, dependency, function(err, mole) { var result = this.addMole(mole); ... this.buildMole(mole, function(err) { ... // 构建模块，添加依赖模块 }.bind(this)); }.bind(this)); }; 调用 acorn 解析经 loader 处理后的源文件生成抽象语法树 AST Parser.prototype.parse = function parse(source, initialState) { var ast; if(!ast) { // acorn以es6的语法进行解析 ast = acorn.parse(source, { ranges: true, locations: true, ecmaVersion: 6, sourceType: "mole" }); } ... }; 遍历 AST，构建该模块所依赖的模块 对于当前模块，或许存在着多个依赖模块。当前模块会开辟一个依赖模块的数组，在遍历 AST 时，将 require() 中的模块通过addDependency() 添加到数组中。当前模块构建完成后，webpack 调用 processMoleDependencies 开始递归处理依赖的 mole，接着就会重复之前的构建步骤。 Compilation.prototype.addMoleDependencies = function(mole, dependencies, l, cacheGroup, recursive, callback) { // 根据依赖数组(dependencies)创建依赖模块对象 var factories = []; for(var i = 0; i < dependencies.length; i++) { var factory = _this.dependencyFactories.get(dependencies[i][0].constructor); factories[i] = [factory, dependencies[i]]; } ... // 与当前模块构建步骤相同 } 3. 构建细节 mole 是 webpack 构建的核心实体，也是所有 mole的 父类，它有几种不同子类：NormalMole , MultiMole ,ContextMole , DelegatedMole 等。但这些核心实体都是在构建中都会去调用对应方法，也就是 build() 。来看看其中具体做了什么: // 初始化mole信息，如context,id,chunks,dependencies等。 NormalMole.prototype.build = function build(options, compilation, resolver, fs, callback) { this.buildTimestamp = new Date().getTime(); // 构建计时 this.built = true; return this.doBuild(options, compilation, resolver, fs, function(err) { // 指定模块引用，不经acorn解析 if(options.mole && options.mole.noParse) { if(Array.isArray(options.mole.noParse)) { if(options.mole.noParse.some(function(regExp) { return typeof regExp === "string" ? this.request.indexOf(regExp) === 0 : regExp.test(this.request); }, this)) return callback(); } else if(typeof options.mole.noParse === "string" ? this.request.indexOf(options.mole.noParse) === 0 : options.mole.noParse.test(this.request)) { return callback(); } } // 由acorn解析生成ast try { this.parser.parse(this._source.source(), { current: this, mole: this, compilation: compilation, options: options }); } catch(e) { var source = this._source.source(); this._source = null; return callback(new MoleParseError(this, source, e)); } return callback(); }.bind(this)); }; 对于每一个 mole ，它都会有这样一个构建方法。当然，它还包括了从构建到输出的一系列的有关 mole 生命周期的函数
3. Webpack 怎么用
1. 为什么用 webpack?
他像 Browserify, 但是将你的应用打包为多个文件. 如果你的单页面应用有多个页面, 那么用户只从下载对应页面的代码. 当他么访问到另一个页面, 他们不需要重新下载通用的代码.
他在很多地方能替代 Grunt 跟 Gulp 因为他能够编译打包 CSS, 做 CSS 预处理, 编译 JS 方言, 打包图片, 还有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模块系统, (Angular, ES6). 如果你不知道用什么, 就用 CommonJS.
2. Webpack 给 Browserify 的同学用
对应地:
browserify main.js > bundle.js
webpack main.js bundle.js
Webpack 比 Browserify 更强大, 你一般会用 webpack.config.js 来组织各个过程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};
这仅仅是 JavaScript, 可以随意添加要运行的代码.
3. 怎样启动 webpack
切换到有 webpack.config.js 的目录然后运行:
webpack 来执行一次开发的编译
webpack -p for building once for proction (minification)
webpack -p 来针对发布环境编译(压缩代码)
webpack --watch 来进行开发过程持续的增量编译(飞快地!)
webpack -d 来生成 SourceMaps
4. JavaScript 方言
Webpack 对应 Browsserify transform 和 RequireJS 插件的工具称为 loader. 下边是 Webpack 加载 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的参数
]
}
};
要开启后缀名的自动补全, 你需要设置 resolve.extensions 参数指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 现在可以写 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};
5. 样式表和图片
首先更新你的代码用 require() 加载静态资源(就像在 Node 里使用 require()):
require('./bootstrap.css');
require('./myapp.less');
var img = document.createElement('img');
img.src = require('./glyph.png');
当你引用 CSS(或者 LESS 吧), Webpack 会将 CSS 内联到 JavaScript 包当中, require() 会在页面当中插入一个 ｀<style>标签. 当你引入图片, Webpack 在包当中插入对应图片的 URL, 这个 URL 是由require()` 返回的.
你需要配置 Webpack(添加 loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
path: './build', // 图片和 JS 会到这里来
publicPath: 'http://mycdn.com/', // 这个用来成成比如图片的 URL
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, // 用 ! 来连接多个人 loader
{ test: /\.css$/, loader: 'style-loader!css-loader' },
{test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} // 内联 base64 URLs, 限定 <=8k 的图片, 其他的用 URL
]
}
};
6. 功能开关
有些代码我们只想在开发环境使用(比如 log), 或者 dogfooging 的服务器里边(比如内部员工正在测试的功能). 在你的代码中, 引用全局变量吧:
if (__DEV__) {
console.warn('Extra logging');
}
// ...
if (__PRERELEASE__) {
showSecretFeature();
}
然后配置 Webpack 当中的对应全局变量:
// webpack.config.js
// definePlugin 接收字符串插入到代码当中, 所以你需要的话可以写上 JS 的字符串
var definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
plugins: [definePlugin]
};
然后你在控制台里用 BUILD_DEV=1 BUILD_PRERELEASE=1 webpack 编译. 注意一下因为 webpack -p 会执行 uglify dead-code elimination, 任何这种代码都会被剔除, 所以你不用担心秘密功能泄漏.
7. 多个进入点(entrypoints)
比如你用 profile 页面跟 feed 页面. 当用户访问 profile, 你不想让他们下载 feed 页面的代码. 因此你创建多个包: 每个页面一个 "main mole":
// webpack.config.js
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js' // 模版基于上边 entry 的 key
}
};
针对 profile, 在页面当中插入 <script src="build/Profile.js"></script>. feed 页面也是一样.
8. 优化共用代码
feed 页面跟 profile 页面共用不要代码(比如 React 还有通用的样式和 component). Webpack 可以分析出来他们有多少共用模块, 然后生成一个共享的包用于代码的缓存.
// webpack.config.js
var webpack = require('webpack');
var commonsPlugin =
new webpack.optimize.CommonsChunkPlugin('common.js');
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js'
},
plugins: [commonsPlugin]
};
在上一个步骤的 script 标签前面加上 <script src="build/common.js"></script> 你就能得到廉价的缓存了.
9. 异步加载
CommonJS 是同步的, 但是 Webpack 提供了异步指定依赖的方案. 这对于客户端的路由很有用, 你想要在每个页面都有路由, 但你又不像在真的用到功能之前就下载某个功能的代码.
声明你想要异步加载的那个"分界点". 比如:
if (window.location.pathname === '/feed') {
showLoadingState();
require.ensure([], function() { // 语法奇葩, 但是有用
hideLoadingState();
require('./feed').show(); // 函数调用后, 模块保证在同步请求下可用
});
} else if (window.location.pathname === '/profile') {
showLoadingState();
require.ensure([], function() {
hideLoadingState();
require('./profile').show();
});
}
Webpack 会完成其余的工作, 生成额外的 chunk 文件帮你加载好.
Webpack 在 HTML script 标签中加载他们时会假设这些文件是怎你的根路径下. 你可以用 output.publicPath 来配置.
// webpack.config.js
output: {
path: "/home/proj/public/assets", // path 指向 Webpack 编译能的资源位置
publicPath: "/assets/" // 引用你的文件时考虑使用的地址
}
4. Webpack有哪些核心分别都代表了什么
有四个核心：
1.入口文件：entr
入口文件根据依赖关系确定要打包的内容 可以将入口文件认为是第一个启动文档。
2.出口：output
可以控制webpack如何向硬盘写入编译文件 在webpack中配置output属性的最低要求是 将他的值设置值为一个对象 包括path 和 filename Path 是目标输出目录的绝对路径 Filename 是用于输出文件的文件名。
3.Loader
可以是在import或者加载模块时与处理文件 也就是类似于其他构件工具中“任务” 并且提供了前端构建步骤的强大方法。Loader中有两个目标 一是识别中被对应的loader进行转换的那些文件 二是转换这些文件 使其能够被添加到依赖图中。
4.插件
插件是webpack的支柱功能 webpack自身也是构建与插件系统之上 插件的目的在于解决loader无法解决的其他事。 （BY三人行慕课）
5. 什么是WebPack，为什么要使用它
1. 为什么用 webpack?
他像 Browserify, 但是将你的应用打包为多个文件. 如果你的单页面应用有多个页面, 那么用户只从下载对应页面的代码. 当他么访问到另一个页面, 他们不需要重新下载通用的代码.
他在很多地方能替代 Grunt 跟 Gulp 因为他能够编译打包 CSS, 做 CSS 预处理, 编译 JS 方言, 打包图片, 还有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模块系统, (Angular, ES6). 如果你不知道用什么, 就用 CommonJS.
2. Webpack 给 Browserify 的同学用
对应地:
browserify main.js > bundle.js
webpack main.js bundle.js
Webpack 比 Browserify 更强大, 你一般会用 webpack.config.js 来组织各个过程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};
这仅仅是 JavaScript, 可以随意添加要运行的代码.
3. 怎样启动 webpack
切换到有 webpack.config.js 的目录然后运行:
webpack 来执行一次开发的编译
webpack -p for building once for proction (minification)
webpack -p 来针对发布环境编译(压缩代码)
webpack --watch 来进行开发过程持续的增量编译(飞快地!)
webpack -d 来生成 SourceMaps
4. JavaScript 方言
Webpack 对应 Browsserify transform 和 RequireJS 插件的工具称为 loader. 下边是 Webpack 加载 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的参数
]
}
};
要开启后缀名的自动补全, 你需要设置 resolve.extensions 参数指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 现在可以写 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};
6. webpack 怎么直接实时编译输出文件
使用webpack编译打包react是非常便捷的。这也是人们常用的一种方式。但是在使用过程中，一定要注意一个细节，那就是webpack和babel-loader的安装位置。react安装当然，使用react必须先安装react和react-dom，其安装方式很简单（前提是我们必须安装有npm）。#npminstallreactreact-dom–savereact安装就这样简单，其实react和react-dom就是相当于js类库。但是我们需要解析器来解析react的语法。react解析器babel安装babel安装的位置是我们这篇文章的目的。babel有两种安装的位置：一种是全局安装，一种是本地安装——也就是安装在项目目录下的node_moles下。#npminstallbabel-corebabel-loaderbabel-preset-react–save-dev//本地安装#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安装一般情况下我们选择本地安装，这样便于管理。打包工具webpack的安装同样，webpack的安装位置也是这篇文章描述的所要注意的点。当然，它也有两种安装的位置：全局安装和本地安装。#npminstallwebpack–save-dev//本地安装#npminstallwebpack–g//全局安装如果选择本地安装，那么在使用的时候较麻烦一些，我们需要在命令前加上路径。所以一般情况下都是全局安装，这样就可以在任意位置直接使用。这里我们选择全局安装。这样才能出现我们将要说的问题。webpack配置文件编写安装完webpack以后，下面来编写webpack配置文件webpack.config.js。这里我不写全部，只写加载loader部分。代码一mole:{loaders:[{test:/\.js$/,loader:'babel',query:{presets:['react']}}]}编译过程中出现的错误好了，到了关键的地方了。现在我们整个系统的配置是这样的：babel安装到本地，webpack安装到全局位置，webpack配置文件如代码一所示。接下来我们就要编译打包我们的项目。#webpack执行该命令以后，你会发现出现如下的错误：ERRORin(webpack)/~/node-libs-browser/~/process/browser.jsMolebuildfailed:Error:Couldn'tfindpreset"react"relativetodirectory"/node/lib/node_moles/webpack/node_moles/node-libs-browser/node_moles/process"……这也就是说找不到babel-preset-react。好了，说了这么多终于在这里引出了我们将要讨论的问题（这里大家不要嫌我啰嗦，为什么出现这种问题，其原因总要弄清楚。什么样的配置会出现这种问题，了解以后才容易上手解决）。解决问题的方式出现上述问题以后，我们有这样三种方式可以解决。方式一要解决这个问题很简单。我们知道，出现这个问题是因为bable和webpack安装的位置不同，所以找不到babel-preset-react。因为在配置文件中有这样一段代码。query:{presets:['react']}好了，既然知道是安装位置不同，那我们可以将babel安装在全局位置，这样这个问题不就解决了吗。#npmremovebabel-corebabel-loaderbabel-preset-react–save-dev//首先移除原先安装的babel#npminstallbabel-corebabel-loaderbabel-preset-react–g//全局安装没错，问题解决了。但是我们不推荐使用这种方式。因为这样不便于管理，所以还是使用其他的方式。方式二此种方式和方式一大同小异。方式一是改变babel的安装位置，而这里是改变webpack的安装位置。原先webpack是安装到全局位置的，所以找不到安装到本地项目目录下的babel-preset-react。因此我们可以改变webpack的位置。#npmremovewebpack–g//移除原先的webpack#npminstallwebpack–save-dev//将webpack安装到本地位置——也就是项目目录下的node_moles中#ln–s/项目根目录/node_moles/webpack/bin/webpack.js/usr/bin/webpack//为了使用webpack方便，在这里我们在/usr/bin目录下建立软连接（也就是快捷方式）//这样我们就可以在任意位置直接使用webpack命令了。此时我们已经改变了webpack的安装位置。现在二者同在项目目录下安装。所以可以正确编译了。此种方式较方式一，我个人比较推荐这种方式，这样比较方便管理。但是，这种方式也不是没有弊端。如果我们有多个项目，那我们就需要在每个项目下都安装webpack，那岂不是很麻烦。所以这种方式也不是很好。方式三该方式应该说是最值得推荐的，因为不需要改变webpack和babel的安装位置。webpack还是在全局位置，babel还是在本地项目位置下。我们需要做的就是修改webpack的配置文件，在代码一的基础上添加一句代码。代码二mole:{loaders:[{test:/\.js$/,loader:'babel',exclude:/node_moles/,query:{presets:['react']}}]}
7. webpack 打包怎么优化的
解决webpack打包的文件体积过大的问题：
确实，每次打包从入口开始，会parse所有的依赖，多的时候竟然打包一次要2秒多，简直不能忍。然而，有几个解决方案，最有效的，是使用weboack的watch，只有文件md5变化时，才会重新打包，并且只parse有变化的文件，其他没变化的文件是使用缓存的。这样子，打包时间迅速降到200ms以内。 再优化下去的话，我们要知道webpack打包的过程中做了啥，首先是解析依赖啦，然后就是各种各样的loader。从解析依赖的角度入手，我们可以bower install一些打包好的文件，然后通过设置别名让依赖指向这个文件，这样就减去了第三方库的依赖解析时间。 然后各种各样的loader也是很耗时的，一种办法是在loader里面配include，让loader只针对特殊资源。
8. vue和angular 编译速度谁更快
框架之间的对比虽然是老生常谈，但也确实是绕不过去的话题，Vue本身的文档里也直接就有和其他框架的对比。同为开源的技术方案，比较本身其实没有任何问题，但在写Vue与其他框架的比较的时候，我们尽力做到两点：
1. 确保事实的准确性。有的就是有，没有就是没有，不确定的就不说，弄错了一定改。
2. 确保语气的中立性。别人的缺点指出但不嘲讽，优点大方承认。
之前 @汪志成 对Vue跟 Angular 的比较文案提出了意见，我们也对应地进行了修订。也欢迎社区继续进行监督和反馈 —— 比较的目的不是扭曲大家的认知，而是为了帮助大家做出自己的判断。
现在说回来大漠（后面都用大漠指代，注意跟 w3cplus@大漠老师不是一个人，对不住了哈哈）的这篇文章，很遗憾，以上两点都不及格。
先说事实。
CLI/工具链
首先两个框架 CLI 的定位不一致。vue-cli 不是一个打包工具，它只是一个 scaffold，也就是初始化工具。真正负责打包的是初始化之后项目内的 webpack 配置和 npm 脚本。从一开始vue-cli 就是这样的设计意图，项目真正的工具链在项目模板里面而不是 CLI 里面。
相比之下 @angular/cli 是一个全包式的命令行工具，一切都是通过 `ng` 来执行，但这不代表 `ng` 有的命令Vue就没有对应的功能 —— 比如在vue-cli 生成的项目里面：
npm run dev 对应 ng serve
npm run build 对应 ng build
npm run lint 对应 ng lint
npm run unit 对应 ng test
npm run e2e 对应 ng e2e
除了 i18n 之外，@angular/cli 有的Vue都有。‘很多日常开发必备的功能都需要开发者自己去下载配置第三方的Node模块’这句话是一个事实上的错误。看起来大漠连vue-cli 生成的项目都没跑过就急着写文章了呢。
其次，CLI 命令/参数多 =更优秀？并没有这样的道理，create-React-app 估计要哭晕在厕所了。如果我们仔细看看文中的截图，ng build 的多个参数，其实就是对应不同的底层 webpack 配置。说实话，我相信不仅仅是我，对于很多其他开发者而言，更宁可直接阅读 webpack 的文档来调整真正的 webpack 配置（并且可以 commit 进项目），而不是去额外学习一套由 Angular 封装的抽象，因为实际生产中需求千变万化，完全被 CLI 封装的配置不利于二次开发。
实事求是地说，@angular/cli 确实有一些值得学习的地方，比如 ng serve 对 SSL 的支持。我们也会在新版本的vue-cli 中持续吸收改进，但连vue-cli 能做什么都没弄清楚就拿玩具来打比方，只能贻笑大方了。
异步加载模块
我不知道为什么大漠又截了个不知哪里的旧中文文档的图，还没截全 —— 最新的关于异步加载的文档是下面这两个链接：
文档中关于异步组件的部分
路由文档关于路由懒加载的部分
Vue将一个组件（以及其所有依赖）改为异步加载，所需要的只是把：
改成
就这么简单。这里注意三点：
当这样分割的时候，该组件所依赖的其他组件或其他模块都会自动被分割进对应的 chunk 里，不存在大漠所暗示的‘手动改 500 个组件’这样的情况。况且两边代码分割的功能都是 webpack 提供的，我真不知道大漠是真的不懂还是故意误导。
所谓的路由级别的分割，只需要把这个组件作为路由组件就可以了，甚至连路由配置表都不用改。
更重要的是这样的异步组件并不一定只能用在路由层面 —— 任何你要用到一个组件的地方，都可以用异步组件无缝替换之，这种灵活性是 Angular 的 loadChildren 根本无法比拟的。比如一个动态的长表单页面，你甚至可以根据用户目前的输入来动态抓取表单接下来的部分（这个用例还是 wepback 的维护者 Sean Larkin 发现并用在生产中的）。
单元测试和集成测试
—— 事实错误。vue-cli 的 webpack 模板内置了开箱即用的 Karma + Jasmine 配置，自带了一个初始测试用例，npm run unit 即可。这又双一次证明大漠根本没有跑过vue-cli 生成的项目。
Vue的单测不仅仅支持 Karam + Jasmine - 事实上社区有广泛的单测反馈，对于 Jest, Ava 都有实践，我们正在开发中的官方的单测工具库vue-test-utils （由社区最流行的单测库 avoriaz 的开发者开发）会进一步简化常见的组件单测断言需求，并且还会有和所有主流 test runner 的整合指南。
—— again，事实错误。vue-cli 的 webpack 模板内置了开箱即用的 Nightwatch + Selenium E2E 测试配置，自带了一个初始测试用例，npm run e2e 即可。这又双叒一次证明大漠根本没有跑过vue-cli 生成的项目。
—— 集成测试这种东西，有什么技术门槛可言，还需要抄么？顺便说一句，vue-cli 初始化的项目可是早比 @angular/cli 正式发布前就已经自带集成测试了...
9. 如何加快webpack打包效率
1. 打包多个页面的js文件 读取src/views下的目录，约定每一个目录当成一个页面，打包成一个js chunk。 2. 打包多个html 循环生成多个HtmlWebpackPlugin插件，把每一个插件的chunks各自指向上面打包的js chunk。