It's only too late if you decide it is. Get busy living. or get busy dying!有则笑话，如此讲到：“老丈人爱吃核桃，昨天买了二斤陪妻子送去，老丈人年轻时练过武，用手一拍核桃就碎了，笑着对我说：你还用锤子，你看我用手就成。我嘴一抽，来了句：人和动物最大的区别就是人会使用工具。……”。撇开这样特例场景，这句话还是非常用有道理的；毕竟从远古石器时期或更早，到如今，所言之语，所穿之衣，代步之车，所学的知识，所晓的常识…..皆是工具；可以说绝大部分人之间的差异(天才级除外)，仅在于工具使用之优劣罢了。在工具的使用中，很多人极大程度上停留于会用层面，如若不遇到问题，几乎就处于停滞；这本身倒也没有问题，但可能因为没有透彻的了解，而错失了对该物可以拥有的想象力，从而错过了许多本该有的美好，如此的可惜。坦白说，在从事前端方面工作，蛮长一段时间内，就因缺乏对 Npm 有足够的认知，使得后来对其诸多讯息，颇感「相见恨晚」；在本篇中，将客观陈述 Npm 与 Yarn 的各自功用，以此显出两者间的差异；同时，以比较的形式，列出「常用命令清单」，以方便使用之时，作为参考(将陆续更新以完善)；同时也欲借此，再次倡导那经典名言：「工欲善其事，必先利其器」，与诸君共勉。什么是 Npm，Yarn什么是 npm？npm 即：，是一种重用其他开发人员的代码的方法，也是一种与他人共享代码的方式，并且可以很容易地管理不同版本的代码。npm 开始作为 Node 包管理器，所以你会发现很多模块可以在服务器端使用。也有很多的包添加命令供您在命令行中使用。你还会发现可以在前端使用的软件包。npm 由三个不同的部分组成：网站，注册表和 CLI 。该网站是用户发现软件包的主要工具，注册表是一个关于软件包信息的大型数据库，而 CLI 则是开发者如何在注册表上发布他们的软件包或下载他们希望安装的软件包。更多详细内容，可参见 。什么是 yarn？Yarn 对你的代码来说是一个包管理器， 你可以通过它使用全世界开发者的代码，或者分享自己的代码。 Yarn 做这些快捷、安全、可靠，所以你不用担心什么。通过 Yarn，你可以使用其他开发者针对不同问题的解决方案，使自己的开发过程更简单。 使用过程中遇到问题，你可以将其上报或者贡献解决方案。一旦问题被修复，Yarn会更新保持同步。Yarn 是 Facebook, Google, Exponent 和 Tilde 开发的一款新的 JavaScript 包管理工具。它并没有试图完全取代 npm。Yarn 同样是一个从 npm 注册源获取模块的新的 CLI 客户端。注册的方式不会有任何变化 —— 你同样可以正常获取与发布包。它存在的目的是解决团队在使用 npm 面临的少数问题。当然，在 Node 版本断更替中，Npm 本身也在积极更新。关于安装/更新如何安装/更新 Npm如何安装 Npmnpm 开始作为 Node 包管理器，所以它的安装是跟 Node.js 捆绑在一起的。至于如何安装 Node.js, Npm 官方，在
做了阐述。之前在不同平台尝试更新 Node.js 之时，也是遇到过各种问题，有在
一文做了记载；折腾许久，得出的结论跟官网一致：如果您使用的是OS X或Windows，安装Node.js的最佳方法是：使用 中的一个安装程序。(笔者微注：如是我中国大陆用户，去下载，会是快速的法子)。如何更新 Npmnpm install npm@latest -g （npm install npm -g）更新(重新下载) Node.js如何安装 Yarn对于如何安装 Yarn，Yarn 官方给出了很全面的说明，详见 ；涵盖 MacOs，Windows，Linux 等平台，并且还给出一些备用安装方式，譬如通过 npm 来安装：1npm install --global yarn
当然，Yarn 官方在 有明确讲道：
一般来说, 不推荐通过 npm 安装 Yarn，在用基于 Node 的包管理器安装 Yarn 时，该包未被签名， 并且只通过基本的 SHA1 散列进行唯一完整性检查。这在安装系统级应用时有安全风险。因为这些原因，高度推荐用你的操作系统最适合的方式来安装 Yarn。
但在实际使用中，这倒是最为方便的方式之一，迄今倒也没遇到什么问题；当然，最好按照官方推荐的方式；如果你使用并熟悉 Mac 操作系统，用推荐方式安装 Yarn 也是很简单：brew install yarn(笔者注)。
如何更新 Yarn对于如何更新 Yarn，可以结合安装时候对应命令；如果是 Mac 操作系统，使用 brew 安装，那么如此操作予以更新：1brew upgrade yarn
如果 Yarn 通过 Debian / Ubuntu 包安装，则可以运行如下命令予以更新：
1sudo apt-get update && sudo apt-get install yarn
也可以使用 yarn 本身来更新自己：1yarn global add yarn
如果有意了解更多如何更新 yarn 的方法，可参见：。
npm 与 yarn 常用命令对比有所区别的命令
npm install(npm i)
yarn install(yarn)
根据 package.json 安装所有依赖
npm i –save [package]
yarn add [package]
添加依赖包
npm i –save-dev [package]
yarn add [package] –dev
添加依赖包至 devDependencies
npm i -g [package]
yarn global add [package]
进行全局安装依赖包
npm update –save
yarn upgrade [package]
升级依赖包
npm uninstall [package]
yarn remove [package]
移除依赖包
相同操作的命令
运行 package.json 中预定义的脚本
npm config list
yarn config list
查看配置信息
npm config set registry 仓库地址
yarn config set registry 仓库地址
更换仓库地址
互动式创建/更新 package.json 文件
查看当前目录下已安装的node包
yarn login
保存你的用户名、邮箱
npm logout
yarn logout
删除你的用户名、邮箱
npm outdated
yarn outdated
检查过时的依赖包
开发时链接依赖包，以便在其他项目中使用
npm unlink
yarn unlink
取消链接依赖包
npm publish
yarn publish
将包发布到 npm
测试 = yarn run test
显示 bin 文件所在的安装目录
显示一个包的信息
对于以上还须对于，还须做如下补充性说明：
在 npm 中，可以使用 npm config set save true 设置 —-save 为默认行为，但这对多数开发者而言，并非显而易见的。而使用 yarn，在package.json 中添加（add）和移除（remove）等行为是默认的。
对于要添加或升级的包，npm 与 yarn 都可以指定具体的版本，或者 Tag；如：
yarn add [package]@[version]yarn add [package]@[tag]
在国内，使用 npm，最好还是替换成淘宝的镜像，如此网络影响减小到最低，这样安装依赖包的速度，可以得到蛮大的改善：
npm config set registry yarn config set registry
当然也可以设置别名 cnpm：
1alias cnpm="npm --registry=http://registry.cnpmjs.org --cache=$HOME/.npm/.cache/cnpm"
Npm 独有的命令
: 用于更改包内容后进行重建；比如常见的 npm rebuild node-sass；当使用 Sass（Scss） 来作样式表预处理器，再打包的时候，你可能会遇见如下错误；而解决此问题，最为简单的方式即使用 rebuild 命令，对
进行重建即可。
Module build failed: ModuleBuildError: Module build failed: Error: Node Sass does not yet support your current environment: This usually happens because your environment has changed since running npm install. Run npm rebuild node-sass to build the binding for your current environment.
Yarn 独有的命令
：依据原npm安装后的node_modules目录生成一份yarn.lock文件；
：列出已安装包的许可证信息；
：创建一个压缩的包依赖 gzip 档案；
：显示有关一个包为何被安装的信息。
：从包依赖里清除并移除不需要的文件。
npm 使用之额外技巧如何寻找适宜的 npm 包找到合适的软件包可能相当具有挑战性 ——，毕竟有成千上万个模块供你选择。 ，这个网站的存在，让这项任务轻松很多；它显示了质量，受欢迎程度和维护等指标。这些计算是基于模块是否具有过时的依赖关系，是否配置了linters，是否包含测试或是否进行了最近的提交。
执行 npm 包的二进制文件显而易见，经由 npm 或是 yarn 安装，并被放置在 ./node_modules 目录中的包，其二进制可执行文件可访问 ./node_modules/.bin，那么该如何从项目根目录中调用它呢？以下提供了几种方式，你可以从中任意选择一种，来达到你的目的：
为了方便举例，这里以运行 （制作更好的响应式邮件模板）作为示例来作说明；其中有用到
这个库；此库被推荐的方式是在本地安装和使用；所以，要运行对应命令，你可以操作她，使用以下办法：
古老而原始的办法
在你安装 MJML 的文件夹中，你现在可以运行：
1./node_modules/.bin/mjml --watch src/index.mjml -o dist/index.html
将 ./node_modules/.bin/ 添加至环境变量
12export PATH="$PATH:./node_modules/.bin"mjml --watch src/index.mjml -o dist/index.html
或者使用快捷键 npm bin
1$(npm bin)/mjml --watch src/index.mjml -o dist/index.html
或者利用 npm 脚本命令
1234567"scripts": {
"mjml": "mjml --watch src/index.mjml -o dist/index.html"}npm run mjml
或者通过使用
注意： 包含在 npm & v5.2，或可以分开安装。
12# npm install -g npxnpx mjml --watch src/index.mjml -o dist/index.html
如何管理 Node 版本众所周知，Node 版本的迭代速度很快，且开发者也比较能及时使用新版本开发；但，对于维护早期的项目，切换 node 版本就成了一个问题；幸好的是，已经有了比较成熟的几个方案；比如盛名遐迩的
以及 @tj 大神的 ；相比之下，n 使用与安装都会更简单，这也完全是作者理念的呈现；其区别主要是：
n 是须要基于 node 环境，它是全局安装的一个 npm 包；在安装之时，n 会先将指定版本的 node 存储下来，然后将其复制到我们熟知的路径 /usr/local/bin，非常简单明了。当然由于 n 会操作到非用户目录，所以需要加 sudo 来执行命令；
nvm 是一个独立软件包：在安装之时，nvm 将不同的 node 版本存储到 ~/.nvm// 下，然后修改 $PATH，将指定版本的 node 路径加入，如此我们调用的 node 命令，即是所指定版本的 node；
如何探查 npm 包一旦我们选择了我们的模块，我们应该看看文档，并检查开放的问题，以更好地了解我们将要在我们的应用程序中需要什么。不要忘记，您使用的 npm 包越多，存在易受攻击或恶意攻击的风险就越高。
如果你想从cli打开模块的主页，你可以这样做：
1npm home axios
要检查未决的问题或公开的路线图（如果有的话），你可以试试这个：
1npm bugs axios
另外，如果你只是想检查模块的 git 仓库，请输入：1npm repo axios
强大如斯，npm 脚本npm（Yarn 亦同）允许在 package.json 文件里面，使用 scripts 字段定义脚本命令。它支持通配符、变量、钩子、外部传参、支持并发 & 异步执行等等；所以，完全可以借助 npm script，打造属于自己的高效工作流。鉴于篇幅，这部分就不在这里多做赘述，具体使用以及运行原理等，可以参见 @阮一峰 所写的文章：。
具体例子来说，有些时候会有需求要删除 Git 仓库所有提交历史，而保留代码为当前状态；而删除 .git 文件夹可能会导致您的 git 存储库中的问题；所以可以使用另一种更为安全的办法：详见。但这个操作一套打下来，不免劳神费力。那么借助 npm script，运行如下命令，一键搞定（当然命令可自行定义）；如果你有需求执行更多，也可以在后面追加更多操作。
12345678910"scripts": {
"clean-commit": "git checkout --orphan latest_branch && git add -A && git commit -am 'clean past commit history ?' && git branch -D master && git branch -m master && git push -f origin master"}"scripts": {
"recommit": "git add -A && git commit -am 'clean past commit history ?'",
"repush": "git branch -D master && git branch -m master && git push -f origin master",
"clean-commit": "git checkout --orphan latest_branch && npm run recommit && repush"}
关于 package-lock.json 和 yarn.lock关于
yarn.lock有时候一个项目周期很长，在不断开发的同时，而依赖的库也会有很大改变；有时候你可能只想运行 npm i 更新没有下载的插件，却不想偶尔会将依赖的一些其他插件更到最新，导致各种奇葩问题；package-lock.json 和 yarn.lock 就是为解决这种问题而设定的存在。
使用 npm 或者 yarn，都会有 pacakge.json 这个文件，用以标出自己项目对 各库包的依赖。举个例子来说，你的项目中有如下依赖：
123"dependencies": {
"jade-package": "^2.3.4"}
这其中的 ^ 是定义了向后(新)兼容依赖；在 npm&5.0 以前，如果 jade-package 的版本超过2.3.4，并在大版本号（2）上相同，就允许下载最新版本的 jade-package 库包，例如实际上可能运行npm i时候，下载的具体版本可能是2.5.8。
多数情况下，这种向后兼容依赖下载最新库包，是没有问题的；然而，因为 npm 是开源世界，各库包的版本语义可能并不相同，不是所有开发者都能严格遵守这一原则：相同大版本号的同一个库包，其接口符合兼容要求。而且，不同的库包之间也存在其他依赖。理想状态下使用语义化版本发布补丁不会包含大的变化，但不幸的是这必非真理。npm 的这种策略，有可能导致两台拥有相同 package.json 文件的机子，实际上安装了不同版本的包，这可能导致一些错误。有时候，相同机器稍不留神的一个
npm i，就可能导致 node_modules 中安装的实际依赖被更新，也就可能导致项目运行呈现，被面目全非。
yarn.lock 就是为解决此问题而衍生的存在；为了跨机器安装得到一致的结果，Yarn 需要比你配置在 package.json 中的依赖列表更多的信息。 Yarn 需要准确存储每个安装的依赖是哪个版本；它类似于 npm 的 npm-shrinkwrap.json，并且无副作用。只是需要注意的是：
yarn.lock 文件是自动产生的，而且应该完全被 Yarn 管理。 当你用 Yarn CLI 增加／升级／删除依赖，它将自动更新你的 yarn.lock 文件。 不要直接编辑这个文件，那样很容易弄坏某些东西。
关于 package-lock.json当 Node.js 升级之 v8.0 以后，自带的 npm 也升级到了5.0；带来速度上很大提升之外，也带来了其他很大变大；这其中就包括 package-lock.json：安装模块操作（改变 node_modules 文件夹内容）会生成或更新 package-lock.json 文件；package-lock.json 之于 npm，即是yarn.lcok 之于 yarn 的翻版；更多信息可参见 。
另外，值得一提的是，在 Github 上有人专门提供了
工具，用以：将yarn.lock转换为package-lock.json，反之亦然（Convert yarn.lock to package-lock.json and vice versa）。
写在文章的最后相比 Npm 的默认配置，Yarn 获赞颇多。用其可以方便生成锁文件，安装依赖非常迅速，且会自动添加进 package.json，同时安装与使用 Yarn 的成本也极小，这使得 Yarn 可以完美替代 npm。yarn 之于 npm，有点像当年的 io.js 和 node.js，殊途同归，都是为了进一步解放和优善生产力；如今，在 Yarn 的影响下，npm 本身也改善不少(version &= 5.0)。最后要说的是，不管用何种工具，全面了解其全貌，知其优晓其劣，方能更好驾驭它，使之为自己高效、快意的生活增姿添色。
@ 于深圳.南山 Last Modify：
您可能会感兴趣的文章：
感谢您的支持，我将继续努力！
扫码打赏，建议金额1-10元
提醒：打赏金额将直接进此方账号，无法退款，请您谨慎操作。
( Start counting from 07 / 13 / 2017 )Instroduction 介绍
现代 Web 应用经常用到bunding tool来创建生产环境的打包文件（例如脚本、样式等），打包文件是需要优化并压缩最小化，同时能够被让用户更快地下载到。在这篇文章中，我们将会利用webpack来贯穿说明如何优化网站资源。这样可以帮助用户更快地加载你的应用同时获得更好的体验。
webpack 目前是最流行的打包工具之一，深入地利用它的特点去优化代码，将脚本拆分成重要和非重要部分，还有剔除无用的代码能够保证你的应用维持最小的带宽和进程消耗。
Note: 我们创建了一个练习的应用来演示下面这些优化的描述。尽力抽更多的时间来练习这些 tips
让我们从现代 web 应用中最耗费资源之一的 Javascript 开始。
Decrease Front-end Size 减少前端体积
当你正在优化一个应用时，首要事情就是尽可能地将它体积的减小。下面就是利用 webpack 如何做。
Enable minification 启用最小化
最小化是通过去除多余空格、缩短变量名等方式压缩代码。例如：
// Original code
function map(array, iteratee) {
let index = -1;
const length = array == null ? 0 : array.
const result = new Array(length);
while (++index & length) {
result[index] = iteratee(array[index], index, array);
// Minified code
function map(n,r){let t=-1;for(const a=null==n?0:n.length,l=Array(a);++t&a;)l[t]=r(n[t],t,n);return l} ``` Webpack 支持两种方式最小化代码：UglifyJS 插件和_loader-specific options_。他们可以同时使用。 [The UglifyJS plugin](https://github.com/webpack-contrib/uglifyjs-webpack-plugin)在 bundle 层级中起作用，在编译之后压缩 bundle。下面来展示如何工作： 1.代码： ```javascript // comments.js import './comments.css'; export function render(data, target) { console.log('Rendered!'); } ``` 2.Webpack 打包后大概是下面这样： ```javascript // bundle.js (part of) &use strict&; Object.defineProperty(__webpack_exports__, &__esModule&, { value: true }); /* harmony export (immutable) */ __webpack_exports__[&render&] = /* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__comments_css__ = __webpack_require__(1); /* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__comments_css_js___default = __webpack_require__.n(__WEBPACK_IMPORTED_MODULE_0__comments_css__); function render(data, target) { console.log('Rendered!'); } ``` 3.使用 UglifyJS 插件压缩最小化后大概是下面这样： ```javascript // minified bundle.js (part of) &use strict&;function t(e,n){console.log(&Rendered!&)} Object.defineProperty(n,&__esModule&,{value:!0}),n.render=t;var o=r(1);r.n(o) ``` 插件集成在 webpack 中，把它的配置在`plugins`中就可以启用： ```javascript // webpack.config.js const webpack = require('webpack'); module.exports = { plugins: [ new webpack.optimize.UglifyJsPlugin(), ], }; ``` 第二种方式_loader-specific options_ 利用 loader options，可以压缩 Uglify 插件无法最小化的部分。举例，当你利用`css-loader`引入一个 CSS 文件时，文件会编译成一个字符串： ```css /* comments.css */ .comment { color: } ``` ↓ ```javascript // minified bundle.js (part of) exports=module.exports=__webpack_require__(1)(), exports.push([module.i,&.comment {\r\n color:\r\n}&,&&]); ``` UglifyJS 不能压缩字符串。要压缩这段 css 内容，需要配置 _loader_ ： ```javascript // webpack.config.js module.exports = { module: { rules: [ { test: /\.css$/, use: [ 'style-loader', { loader: 'css-loader', options: { minimize: true } }, ], }, ], }, }; ``` & Note: UglifyJS 插件不能编译 ES2015+(ES2016)，这意味着如果你的 diamante 中使用类、箭头函数和一些新特性语法，不能编译成 ES5，插件会抛异常。
& 如果需要编译新语法，要使用 [uglifyjs-webpack-plugin](https://github.com/webpack-contrib/uglifyjs-webpack-plugin) 包。也是集成在 webpack 中相同的插件，但是更新一些，能够有能力编译 ES2015+。
#### Further reading
* [The UglifyJsPlugin docs](https://github.com/webpack-contrib/uglifyjs-webpack-plugin)
* Other popular minifiers: [Babel Minify](https://github.com/webpack-contrib/babel-minify-webpack-plugin), [Google Closure Compiler](https://github.com/roman01la/webpack-closure-compiler)
### Specify `NODE_ENV=production` 明确生产环境信息
减小前端体积的另外一个方法就是在代码中将`NODE_ENV`[环境变量](https://superuser.com/questions/284342/what-are-path-and-other-environment-variables-and-how-can-i-set-or-use-them)设置成`production`。
Libraries 会读取`NODE_ENV`变量判断他们应该在那种模式下工作 - 开发模式 or 生成模式。很多库会基于这个变量有不同的表现。举个例子，当`NODE_ENV`没有设置成`production`，Vue.js 会做额外的检查并且输出一些警告：
```javascript
// vue/dist/vue.runtime.esm.js
// …
if (process.env.NODE_ENV !== 'production') {
warn('props must be strings when using array syntax.');
// …
React 也是类似 – 开发模式下 build 带有一些警告：
// react/index.js
if (process.env.NODE_ENV === 'production') {
module.exports = require('./cjs/react.production.min.js');
module.exports = require('./cjs/react.development.js');
// react/cjs/react.development.js
// …
warning$3(
componentClass.getDefaultProps.isReactClassApproved,
'getDefaultProps is only used on classic React.createClass ' +
'definitions. Use a static property named `defaultProps` instead.'
// …
这些检查和警告通常在生产环境下是不必要的，但是他们仍然保留在代码中并且会增加库的体积。通过配置 webpack 的
来剔除掉：
// webpack.config.js
const webpack = require('webpack');
module.exports = {
plugins: [
new webpack.DefinePlugin({
'process.env.NODE_ENV': '&production&',
new webpack.optimize.UglifyJsPlugin(),
DefinePlugin用确定的变量替换所有存在的说明变量。利用下面配置：
1.DefinePlugin将用&production&替换到process.env.NODE_ENV：
// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
name = camelize(val);
res[name] = { type: null };
} else if (process.env.NODE_ENV !== 'production') {
warn('props must be strings when using array syntax.');
// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
name = camelize(val);
res[name] = { type: null };
} else if (&production& !== 'production') {
warn('props must be strings when using array syntax.');
Note: 如果你偏向有通过 CLI 配置变量，可以查看一下 。它和DefinePlugin类似，但读环境并且自动替换process.env表达式。
2.UglifyJS会移除掉所有if分支 – 因为&production& !== 'production'永远返回 false ，插件理解代码内的判断分支将永远不会执行：
// vue/dist/vue.runtime.esm.js
if (typeof val === 'string') {
name = camelize(val);
res[name] = { type: null };
} else if (&production& !== 'production') {
warn('props must be strings when using array syntax.');
// vue/dist/vue.runtime.esm.js (without minification)
if (typeof val === 'string') {
name = camelize(val);
res[name] = { type: null };
Note: 不一定强制要求使用 UglifyJSPlugin。你可以使用其他不同的最小化工具，这些页支持移除无用代码（例如，the
Further Reading
Use ES Modules 使用 ES 模块
下面这个方式利用
减小前端体积。
当你使用 ES module，webpack 有能力去做 tree-shaking。Tree-shaking 贯穿整个依赖树，检查那些依赖被使用，移除无用依赖。因此，如果你使用 ES module 语法，webpack 可以排除掉无用代码：
1.一个有多个 export 的文件，但是 app 只需要其中一个：
// comments.js
export const render = () =& { return 'Rendered!'; };
export const commentRestEndpoint = '/rest/comments';
// index.js
import { render } from './comments.js';
2.webpack 理解 commentRestEndPoint没有使用，同时不能在一个 bundle 中生成单独的 export：
// bundle.js (part that corresponds to comments.js)
(function(module, __webpack_exports__, __webpack_require__) {
&use strict&;
const render = () =& { return 'Rendered!'; };
/* harmony export (immutable) */ __webpack_exports__[&a&] =
const commentRestEndpoint = '/rest/comments';
/* unused harmony export commentRestEndpoint */
3.UglifyJSPlugin移除无用变量：
// bundle.js (part that corresponds to comments.js)
(function(n,e){&use strict&;var r=function(){return&Rendered!&};e.b=r})
如果他们都是有 ES module 编写，就是与一些库并存时也是生效的。
Note: 在 webpack 中，tree-shaking 没有 minifier 是无法生效的。 webpack 仅仅移除了没有被用到的 export 变量；UglifyJSPlugin才会移除无用代码。所以如果你编译打包时没有使用 minifier，打包后体积并不会更小。你也可以不一定使用这个插件。其他最小化的插件也支持移除 dead code（例如： or ）
Warning: 不要将 ES module 编译到 CommonJS 中。 如果你使用 Babel babel-preset-env or babel-preset-es2015，检查一下当前的配置。默认情况下， ES import and export to CommonJS require and module.exports。通过设置 option 来禁止掉。
Futher reading
Optimize images 优化图片
图片基本会占局页面一半以上体积。虽然它们不像 JavaScript 那么重要（比如它们不会阻止页面渲染），但图片仍然会占用掉一大部分带宽。利用url-loader，svg-url-loader和image-webpack-loader来在 webpack 中进行优化。
url-loader 允许将小静态文件打包进 app。没有配置，他需要通过 file，将它放在编译后的打包 bundle 内并返回一个这个文件的 url。然而，如果我们注明limit选项，它将会 encode 成更小的文件 base64 文件 url。这是可以将图片放在Javascript 代码中，同时节省 HTTP 请求：
// webpack.config.js
module.exports = {
test: /\.(jpe?g|png|gif)$/,
loader: 'url-loader',
options: {
// Inline files smaller than 10 kB (10240 bytes)
limit: 10 * 1024,
// index.js
import imageUrl from './image.png';
// → If image.png is smaller than 10 kB, `imageUrl` will include
// the encoded image: 'data:image/base64,iVBORw0KGg…'
// → If image.png is larger than 10 kB, the loader will create a new file,
// and `imageUrl` will include its url: `/2fcd56a1920be.png`
Note: 内联图片减少了独立请求的数量，这是很好的方式（），但是会增加 bundle下载和转换的时间和内存的消耗。一定要确保不要嵌入超大图片或者较多的图片 – 否则增加的 bundle 的时间将会掩盖做成内联图片的收益。
svg-url-loader与url-loader类似 – 都是将使用
encode 文件。这对对于 SVG 图片很奏效 – 因为 SVG 文件是文本，encoding 在体积上更有效率：
// webpack.config.js
module.exports = {
test: /\.svg$/,
loader: 'svg-url-loader',
options: {
// Inline files smaller than 10 kB (10240 bytes)
limit: 10 * 1024,
// Remove the quotes from the url
// (they’re unnecessary in most cases)
noquotes: true,
Note: svg-url-loader 拥有改善 IE 浏览器支持的 options，但是在其他浏览器中更糟糕。如果你需要兼容 IE 浏览器，
image-webpack-loader压缩图片使之变小。它支持 JPG，PNG，GIF 和 SVG，因为我们将会使用它所有类型。
这个 loader 不会将图片嵌入在应用内，因此它必须与url-loader和svg-url-loader配合使用。避免复制粘贴到相同的 rules 中（一个用于 JPG/PNG/GIF 图片，另一个用于 SVG 图片），我们来使用enforce: pre作为单独的一个 rule 涵盖这个 loader：
// webpack.config.js
module.exports = {
test: /\.(jpe?g|png|gif|svg)$/,
loader: 'image-webpack-loader',
// This will apply the loader before the other ones
enforce: 'pre',
默认 loader 设置就已经可以满足需求了 – 但如果你想要深入配置，请查看 。为了选择哪些 options 需要明确，可以查看 Addy Osmani 的
Further reading
Optimize dependencies 优化依赖
平均一半以上的 Javascript 体积大小来源于依赖包，并且这些可能都不是必要的。
举一个例子来说，Lodash（v4.17.4）增加了最小化代码的 72KB 大小到 bundle 中。但是如果你仅仅用到它的20个方法，大约 65 KB 代码没有用处。
另外一个例子就是 Moment.js。 V2.19.1版本最小化后有 223KB，体积巨大 – 截至2017年10月一个页面内的 Javascript 平均体积是 452KB。但是，本地文件的体积占 170KB。如果你没有用到 多语言版 Moment.js，这些文件都会没有目的地使 bundle 更臃肿。
所有这些依赖都可以被轻易优化。我们在 Github repo 收集了优化的建议，！
Enable module concatenation for ES modules (aka scope hoisting)
当你构建 bundle 时，webpack 将每一个 module 封装进 function 中：
// index.js
import {render} from './comments.js';
// comments.js
export function render(data, target) {
console.log('Rendered!');
// bundle.js (part of)
/* 0 */
(function(module, __webpack_exports__, __webpack_require__) {
&use strict&;
Object.defineProperty(__webpack_exports__, &__esModule&, { value: true });
var __WEBPACK_IMPORTED_MODULE_0__comments_js__ = __webpack_require__(1);
Object(__WEBPACK_IMPORTED_MODULE_0__comments_js__[&a& /* render */])();
/* 1 */
(function(module, __webpack_exports__, __webpack_require__) {
&use strict&;
__webpack_exports__[&a&] =
function render(data, target) {
console.log('Rendered!');
在以前，这么做是使 CommonJS/AMD modules 互相分离所必须的。但是，这会增加体积并且性能表现堪忧。
Webpack 2 介绍了 ES modules 的支持，不像 CommonJS 和 AMD modules 一样，而是能够不用将每一个 module 用 function 封装起来。同时 Webpack 3 利用完成这样一个 bundle，下面是例子：
// index.js
import {render} from './comments.js';
// comments.js
export function render(data, target) {
console.log('Rendered!');
// Unlike the previous snippet, this bundle has only one module
// which includes the code from both files
// 与前面的代码不同，这个 bundle 只有一个 module，同时包含两个文件
// bundle.js ( compiled with ModuleConcatenationPlugin)
/* 0 */
(function(module, __webpack_exports__, __webpack_require__) {
&use strict&;
Object.defineProperty(__webpack_exports__, &__esModule&, { value: true });
// CONCATENATED MODULE: ./comments.js
function render(data, target) {
console.log('Rendered!');
// CONCATENATED MODULE: ./index.js
看到区别了吗？在这个 bundle 中， module 0 需要 module 1 的 render 方法。使用 ModuleConcatenationPlugin，require被直接简单的替换成 require 函数，同时 module 1 被删除删除掉了。这个 bundle 拥有更少的 modules，就有更少的 modules 损耗！
启用这个功能，可以在插件列表中增加ModuleConcatenationPlugin：
// webpack.config.js
const webpack = require('webpack');
module.exports = {
plugins: [
new webpack.optimize.ModuleConcatenationPlugin(),
Note：想要知道为什么这个功能不是默认启用？Concatenating modules 很棒， 。这就是为什么只在生产环境中启用的原因了。
Further reading
Use externals if you have both webpack and non-webpack code 如果代码中包含 webpack 和非 webpack 的代码要使用 externals
你可能拥有一个体积庞大的工程，其中一部分代码可以使用 webpack 编译，而有一些代码又不能。比如一个视频网站，播放器的 widget 可能通过 webpack 编译，但是其周围页面区域可能不是：
如果两部分代码有相同的依赖，你可以共享这些依赖以便减少重复下载耗时。就干了这件事 – 它用变量或者外部引用来替代 modules。
如果依赖是挂载到 window 上的情况
如果你的非 webpack 代码依靠这些依赖，它们是挂载 window 上的变量，可以将依赖名称 alias 成变量名：
// webpack.config.js
module.exports = {
externals: {
'react': 'React',
'react-dom': 'ReactDOM',
利用这个配置，webpack 将不会打包 react 和 react-dom包。取而代之，他们会被替换成下面这个样子：
// bundle.js (part of)
(function(module, exports) {
// A module that exports `window.React`. Without `externals`,
// this module would include the whole React bundle
module.exports = R
(function(module, exports) {
// A module that exports `window.ReactDOM`. Without `externals`,
// this module would include the whole ReactDOM bundle
module.exports = ReactDOM;
如果依赖是当做 AMD 包被加载的情况
如果你的非 webpack 代码没有将依赖暴露挂载到 window 上，这就更复杂了。但是如果非 webpack 代码使用 AMD 包的形式消费了这些依赖，你仍然可以避免重复的代码加载两次。
具体如何做呢？将 webpack 代码编译成一个 AMD module 同时别名成一个库的 URLs：
// webpack.config.js
module.exports = {
output: { libraryTarget: 'amd' },
externals: {
'react': { amd: '/libraries/react.min.js' },
'react-dom': { amd: '/libraries/react-dom.min.js' },
Webpack 将会把 bundle 包装进 define()同时让它依赖于这些URLs：
// bundle.js (beginning)
define([&/libraries/react.min.js&, &/libraries/react-dom.min.js&], function () { … });
如果非 webpack 代码使用相同的 URLs 加载依赖，这些文件将会加载一次 – 多余的请求会使用缓存。
Note：webpack 只是替换那些externals对象中的准确匹配的 keys 的引用。这意味着如果你的代码这样写import React from 'react/umd/react.production.min.js'，这个库是不会被 bundle 排除掉的。这是因为 – webpack 并不知道 import 'react' 和 import 'react/umd/react.production.min.js' 是同一个库，这样比较谨慎。
Further reading
Summing up 总结
Minimize your code with the UglifyJsPlugin and loader options
Remove the development-only code with the DefinePlugin
Use ES modules to enable tree shaking
Compress images
Apply dependency-specific optimizations
Enable module concatenation
Use externals if this makes sense for you
Make use of long-term caching 利用好长时缓存
在做完优化应用体积之后的下一步提升应用加载时间的就是缓存。在客户端中使用缓存作为应用的一部分，这样会在每一次请求中减少重新下载的次数。
Use bundle versioning and cache headers 使用 bundle 版本和缓存头信息
做缓存通用的解决办法：
1.告诉浏览器缓存一个文件很长时间（比如一年）
# Server header
Cache-Control: max-age=
Note：如果你不熟悉 Cache-Control 做了什么，你可以看一下 Jake Archibald 的精彩博文
2.当文件改变需要强制重新下载时去重命名这些文件
&!-- Before the change --&
&script src=&./index-v15.js&&&/script&
&!-- After the change --&
&script src=&./index-v16.js&&&/script&
这些方法可以告诉浏览器下载这些 JS 文件，将其缓存起来。浏览器将只会在文件名发生改变时才会请求网络（或者缓存失效的情况也会请求）。
使用 webpack，也可以做同样的事，但可以使用版本号来解决，需要明确这个文件的 hash 值。使用
可以将 hash 值包含进文件名中：
// webpack.config.js
module.exports = {
entry: './index.js',
filename: 'bundle.[chunkhash].js',
// → bundle.8e0d62a03.js
Note: webpack 可能会生成不同的 hash 即使 bundle 相同 – 比如你重名了了一个文件或者重新在不同的操作系统下编译了一个 bundle。
如果你需要将文件名发送给客户端，也可以使用 HtmlWebpackPlugin 或者 WebpackManifestPlugin。
HtmlWebpackPlugin 很简单，但灵活性欠缺一些。编译时，插件会生成一个 HTML 文件，这其中包括所有的编译后的资源文件。如果你的业务逻辑不复杂，这就非常适合你：
&!-- index.html --&
&!doctype html&
&!-- ... --&
&script src=&bundle.8e0d62a03.js&&&/script&
WebpackManifestPlugin更灵活一些，它可以帮助你解决业务负责的部分。编译时它会生成一个 JSON 文件，这文件保存这没有 hash 值文件与有 hash 文件之间的映射。服务端利用这个 JSON 可以识别出那个文件有效：
// manifest.json
&bundle.js&: &bundle.8e0d62a03.js&
Further reading
Extract dependencies and runtime into a separate file 将依赖和运行环境代码提取到一个单独的文件
Dependencies 依赖包
App 依赖通常情况下趋向于比实际 app 内代码中更少的变化。如果你将他们移到独立的文件中，浏览器将可以把他们独立缓存起来 – 同时不会每次 app 代码改变时重新下载。
Key Term: 在 webpack 的技术中，利用 app 代码拆分文件被称为 chunks。我们后面会用到这个名词。
为了将依赖包提取到单独的 chunk 中，下面分为三步：
1.使用[name].[chunkname].js替换output的文件名：
// webpack.config.js
module.exports = {
// Before
filename: 'bundle.[chunkhash].js',
// After
filename: '[name].[chunkhash].js',
当 webpack 构建应用时，它会用一个带有 chunk 的名称来替换[name]。如果没有添加[name]部分，我们不得不通过 chunks 之间的 hash 区别来比较他们的区别 – 那就太难了！
2.将entry转成一个对象：
// webpack.config.js
module.exports = {
// Before
entry: './index.js',
// After
main: './index.js',
在这段代码中，”main” 对象是一个 chunk 的名字。这个名字将会被步骤 1 里面的 [name]代替。目前为止，如果你构建一个 app，chunk 就会包括整个 app 的代码 – 就像我们没有做这些步骤一样。但是很快就会产生变化。
// webpack.config.js
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
// A name of the chunk that will include the dependencies.
// This name is substituted in place of [name] from step 1
name: 'vendor',
// A function that determines which modules to include into this chunk
minChunks: module =& module.context &&
module.context.includes('node_modules'),
插件将包括全部node_modules路径下的 modules 同时将他们移到一个单独的文件中，这个文件被称为 vendor.[chunkhash].js。
完成了上面的步骤，每一次 build 都会生成两个文件。浏览器会将他们单独缓存 – 以便代码发生改变时重新下载。
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
Asset Size Chunks Chunk Names
./main.00bab6fdb0.js 82 kB 0 [emitted] main
./vendor.d9eecdf9483.js 47 kB 1 [emitted] vendor
Webpack runtime code
不幸的是，仅仅抽取vendor是不够的。如果你试图在应用代码中修改一些东西：
// index.js
// E.g. add this:
console.log('Wat');
你会注意到vendor的 hash 值也会改变：
Asset Size Chunks Chunk Names
./vendor.d9eecdf9483.js 47 kB 1 [emitted] vendor
Asset Size Chunks Chunk Names
./vendor.e6eacc1c60b.js 47 kB 1 [emitted] vendor
发生这样的事是因为 webpack 打包时，一部分 modules 的代码，拥有
– 管理模块执行一部分代码。当你将代码拆分成多个文件时，这小部分代码在 chunk ids 和 匹配的文件之间开始了一个映射：
// vendor.e6eacc1c60b.js
script.src = __webpack_require__.p + chunkId + &.& + {
&0&: &2fa55a5c1871&
}[chunkId] + &.js&;
Webpack 将最新生成的 chunk 包含在这个 runtime 内，这个 chunk 就是我们代码中的vendor。与此同时每一次任何 chunk 的改变，这一小部分代码也改变，导致整个 vendor chunk 也会改变。
为了解决这个问题，我们将 runtime 转义到一个独立的文件中，通过CommonsChunkPlugin创建一个额外的空的 chunk：
// webpack.config.js
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: module =& module.context &&
module.context.includes('node_modules'),
// This plugin must come after the vendor one (because webpack
// includes runtime into the last chunk)
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime',
// minChunks: Infinity means that no app modules
// will be included into this chunk
minChunks: Infinity,
完成这一部分改变，每一次 build 都将生成三个文件：
Hash: ac01483e8fec1fa70676
Version: webpack 3.8.1
Time: 3816ms
Asset Size Chunks Chunk Names
./main.00bab6fdb0.js 82 kB 0 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 1 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
将他们反过来顺序添加到 index.html 中，你就搞定了：
&!-- index.html --&
&script src=&./runtime.79f17c27b335abc7aaf4.js&&&/script&
&script src=&./vendor.26886caf15818fa82dfa.js&&&/script&
&script src=&./main.00bab6fdb0.js&&&/script&
Further reading
Inline webpack runtime to save an extra HTTP request 内联 webpack runtime 节省额外的 HTTP 请求
为了做的更好，尽力把 webpack runtime 内联在 HTML 请求里。下面举例：
&!-- index.html --&
&script src=&./runtime.79f17c27b335abc7aaf4.js&&&/script&
&!-- index.html --&
!function(e){function n(r){if(t[r])return t[r].…}} ([]);
&/script&
这个 runtime 很小，内联它可以帮助你节省 HTTP 请求（尤其对 HTTP/1 重要；但是在 HTTP/2 就没有那么重要了，但是仍能够提高效率）。
下面就来看看如何做。
如果使用 HtmlWebpackPlugin 来生成 HTML
来生成 HTML 文件， 就足够了。
如果使用自己的定制服务逻辑来生成 HTML
1.将 runtime 名称改成静态的明确的文件名：
// webpack.config.js
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime',
minChunks: Infinity,
filename: 'runtime.js',
// → Now the runtime file will be called
// “runtime.js”, not “runtime.79f17c27b335abc7aaf4.js”
2.以方便的方式将 runtime.js 嵌入进去。比如：Node.js 和 Express
// server.js
const fs = require('fs');
const runtimeContent = fs.readFileSync('./runtime.js', 'utf-8');
app.get('/', (req, res) =& {
res.send(`
${runtimeContent}
有时候，页面拥有或多或少的部分：
如果你在 YouTube 上加载一个视频页面，相比评论区域你更在乎视频区域。这就是视频要比评论区域重要。
如果你在一个新闻网站打开一个报道，相比广告区域你更关心文章的内容。这就是文字比广告更重要。
在这些案例中，通过仅下载最重要的部分，懒加载剩余区域能够提升最初的加载性能。使用
解决这个问题：
// videoPlayer.js
export function renderVideoPlayer() { … }
// comments.js
export function renderComments() { … }
// index.js
import {renderVideoPlayer} from './videoPlayer';
renderVideoPlayer();
// …Custom event listener
onShowCommentsClick(() =& {
import('./comments').then((comments) =& {
comments.renderComments();
import()明确表示你期望动态地加载独立的 module。当 webpack 看到 import('./module.js')时，他就会将这个 module 移到独立的 chunk 中：
Hash: 39b2a53cb4e73f0dc5b2
Version: webpack 3.8.1
Time: 4273ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./main.f7e53d8e13e9a2745d6d.js 60 kB 1 [emitted] main
./vendor.4f14b2a98.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
并且只在代码执行到 import() 才会下载。
这将会让 main bundle 更小，提升初始加载的时间。更重要的是改进缓存 – 如果你修改 main chunk 的代码，其他部分的 chunk 也不会受影响。
Note: 如果使用 Babel 编译代码，你会因为 Babel 还不认识 import() 而遇到语法错误抛出来。可以使用
解决这个错误。
Further reading
Split the code into routes and pages 拆分代码到路由和页面中
如果你的应用拥有多个路由或者页面，但是代码中只有单独一个 JS 文件（一个单独的 main chunk），这看起来你正在每一个请求中节省额外的 bytes 带宽。举个例子，当用户正在访问你网站的首页：
他们并不需要加载另外不同的页面上渲染文章标题的的代码 – 但是他们还是会加载到这段代码。更严重的是如果用户经常只访问首页，同时你还经常改变渲染文章标题的代码，webpack 将会对整个 bundle 失效 – 用户每次都会重复下载全部 app 的代码。
如果我们将代码拆分到页面里（或者单页面应用的路由里），用户就会只下载对他有意义的代码。更好的是，浏览器也会更好地缓存代码：当你改变首页的代码时，webpack 只会让相匹配的 chunk 失效。
For single-page apps 对于单页面应用
通过路由拆分带页面引用，使用 import()（看看 这部分）。如果你在使用一个框架，现在已经有成熟的方案：
For traditional multi-page apps 对于传统的多页面应用
通过页面拆分传统多页面应用，可以使用 webpack 的
。如果你的应用有三种页面：主页、文章页、用户账户页，那就分厂三个 entries：
// webpack.config.js
module.exports = {
home: './src/Home/index.js',
article: './src/Article/index.js',
profile: './src/Profile/index.js'
对于每一个 entry 文件，webpack 将构建出独立的依赖树，并且声称一个 bundle，它将通过 entry 来只包括用到的 modules：
Hash: 318d7bbf23b
Version: webpack 3.8.1
Time: 4273ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./home.91b9ed2d6a.js 18 kB 1 [emitted] home
./article.87aac3294fd.js 32 kB 2 [emitted] article
./profile.de945dc1.js 24 kB 3 [emitted] profile
./vendor.4f14b2a98.js 46 kB 4 [emitted] vendor
./runtime.318d7bbf23b.js 1.45 kB 5 [emitted] runtime
因此，如果仅仅是文章页使用 Lodash ，home 和 profile 的 bundle 将不会包含 lodash – 同时用户也不会在访问首页的时候下载到这个库。
拆分依赖树也有缺点。如果两个 entry points 都用到了 loadash ，同时你没有在 vendor 移除掉依赖，两个 entry points 将包括两个重复的 lodash 。我们可以使用来解决这个问题 – 它会将通用的依赖转移到一个独立的文件中：
// webpack.config.js
module.exports = {
plugins: [
new webpack.optimize.CommonsChunkPlugin({
// A name of the chunk that will include the common dependencies
name: 'common',
// The plugin will move a module into a common file
// only if it’s included into `minChunks` chunks
// (Note that the plugin analyzes all chunks, not only entries)
minChunks: 2, // 2 is the default value
随意使用minChunks的值来找到最优的选项。通常情况下，你想要它尽可能体积小，但它会增加 chunks 的数量。举个例子，3 个 chunk，minChunks 可能是 2 个，但是 30 个 chunk，它可能是 8 个 – 因为如果你把它设置成 2 ，过多的 modules 将会打包进一个通用文件中，文件更臃肿。
Further reading
Make module ids more stable 让 module ide 更稳定
当编译代码时，webpack 会分配给每一个 module 一个 ID。之后，这些 ID 就会被require()引用到 bundle 内部。你可以在编译输出的右侧在 moudle 路径之前看到这些 ID：
Hash: df28e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.8ecaf182f5c85b7a8199.js 22.5 kB 0 [emitted]
./main.4e50aa9e9.js 60 kB 1 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
[0] ./index.js 29 kB {1} [built]
[2] (webpack)/buildin/global.js 488 bytes {2} [built]
[3] (webpack)/buildin/module.js 495 bytes {2} [built]
[4] ./comments.js 58 kB {0} [built]
[5] ./ads.js 74 kB {1} [built]
+ 1 hidden module
默认情况下，这些 ID 是使用计数器计算出来的（比如第一个 module 是 ID 0，第二个 moudle 就是 ID 1，以此类推）。这样的问题就在于当你新增一个 module 事，它会出现在原来 module 列表中的中间，改变后面所有 module 的 ID：
Hash: df28e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.5c82c0f337fcb22672b5.js 22 kB 0 [emitted]
./main.0c8b617dfc40c2827ae3.js 82 kB 1 [emitted] main
./vendor.26886caf15818fa82dfa.js 46 kB 2 [emitted] vendor
./runtime.79f17c27b335abc7aaf4.js 1.45 kB 3 [emitted] runtime
[0] ./index.js 29 kB {1} [built]
[2] (webpack)/buildin/global.js 488 bytes {2} [built]
[3] (webpack)/buildin/module.js 495 bytes {2} [built]
↓ 我们增加一个新 module
[4] ./webPlayer.js 24 kB {1} [built]
↓ 现在看这里做了什么！comments.js现在的 ID 由 4 变成了 5
[5] ./comments.js 58 kB {0} [built]
↓ ads.js 的 ID 由 5 变成 6
[6] ./ads.js 74 kB {1} [built]
+ 1 hidden module
这将使包含或依赖于具有更改ID的模块的所有块无效 – 即使它们的实际代码没有更改。在我们的代码中，_0_这个 chunk 和 main chunk 都会失效 – 只有_main_才应该失效。
使用插件改变module ID 如何计算来解决这个问题。它利用 module 路径的 hash 来替换掉计数器：
Hash: df28e3bbc9
Version: webpack 3.8.1
Time: 2150ms
Asset Size Chunks Chunk Names
./0.6168aaac8461862eab7a.js 22.5 kB 0 [emitted]
./main.a2e49ab91.js 60 kB 1 [emitted] main
./vendor.ff9f7eaa84c8.js 46 kB 2 [emitted] vendor
./runtime.25f5dfa57a1.js 1.45 kB 3 [emitted] runtime
[3IRH] ./index.js 29 kB {1} [built]
[DuR2] (webpack)/buildin/global.js 488 bytes {2} [built]
[JkW7] (webpack)/buildin/module.js 495 bytes {2} [built]
[LbCc] ./webPlayer.js 24 kB {1} [built]
[lebJ] ./comments.js 58 kB {0} [built]
[02Tr] ./ads.js 74 kB {1} [built]
+ 1 hidden module
有了这个方法，只有你重命名护着删除这个 moudle 它的 ID 才会变化。新的 modules 不会因为 module ID 互相影响。
启用这个插件，在配置中增加 plugins：
// webpack.config.js
module.exports = {
plugins: [
new webpack.HashedModuleIdsPlugin(),
Further reading
Summing up
Cache the bundle and differentiate between them by changing their names
Split the bundle into app code, vendor code and runtime
Inline the runtime to save an HTTP request
Lazy-load non-critical code with import
Split code by routes/pages to avoid loading unnecessary stuff
Monitor and analyze the app 监控并分析
即使当你配置好你的 webpack 让你的应用尽可能体积较小的时候，跟踪这个应用就非常重要，同时了解里面包含了什么。除此之外，你安装一个依赖，它将让你的 app 增加两倍大小 – 但并没有注意到这个问题！
这一部分就来讲解一些能够帮助你理解你的 bundle 的工具。
Keep track of the bundle size 跟踪打包的体积
在开发时可以使用和命令行 来监控 app 的体积。
webpack-dashboard
可以通过依赖体积大小、进程和其他细节来改进 webpack 的输出。
这个 dashborad 帮助我们跟踪大型依赖 – 如果你增加一个依赖，你就立刻能在 Modules section 始终看到它！
启用这个功能，需要安装 webpack-dashboard 包：
npm install webpack-dashboard --save-dev
同时在配置的 plugins 增加：
// webpack.config.js
const DashboardPlugin = require('webpack-dashboard/plugin');
module.exports = {
plugins: [
new DashboardPlugin(),
或者如果正在使用基于 Express dev server 可以使用 compiler.apply()：
compiler.apply(new DashboardPlugin());
多尝试 dashboard 找出改进的地方！比如，在 modules section 滚动找到那个库体积过大，把它替换成小的可替代的库。
bundlesize
可以验证 webpack assets 不超过指定的大小。通过自动化 CI 就可以知晓 app 是否变的过于臃肿：
配置如下：
Find out the maximum sizes 找出最大体积
1.分析 app 尽可能减小体积，执行生产环境的 build。
2.在package.json中增加bundlesize部分：
// package.json
&bundlesize&: [
&path&: &./dist/*&
3.使用npx执行bundlesize：
npx bundlesize
它就会将每一个文件的 gzip 压缩后的体积打印出来：
PASS ./dist/icon256.6168aaac8461862eab7a.png: 10.89KB PASS./dist/icon512.c3e073aa86.png: 13.1KB PASS./dist/main.0c8b617dfc40c2827ae3.js: 16.28KB PASS./dist/vendor.ff9f7eaa84c8.js: 31.49KB
4.每一个体积增加10-20%，你将得到最大体积。这个10-20％的幅度可以让你像往常一样开发应用程序，同时警告你，当它的大小增长太多。
Enable bundlesize 启用 bundlesize
5.安装_bundlesize_开发依赖
npm install bundlesize --save-dev
6.在package.json中的bundlesize部分，声明具体的最大值。对于某一些文件（比如图片），你可以单独根据文件类型来设置最大体积大小，而不需要根据每一个文件：
// package.json
&bundlesize&: [
&path&: &./dist/*.png&,
&maxSize&: &16 kB&,
&path&: &./dist/main.*.js&,
&maxSize&: &20 kB&,
&path&: &./dist/vendor.*.js&,
&maxSize&: &35 kB&,
7.增加一个 npm 脚本来执行检查：
// package.json
&scripts&: {
&check-size&: &bundlesize&
8.配置自动化 CI 来在每一次 push 时执行npm run check-size做检查。（如果你在 Github 上开发项目，直接可以使用。）
这就全部了！现在如果你运行npm run check-size或者 push 代码，你就会看到输出的文件是否足够小：
或者下面失败的情况
Further reading
Analyze why the bundle is so large 分析 bundle 为什么这么大
你想要深挖 bundle 内，看看里面具体哪些 module 占用多大空间。
(Screen recording from )
webpack-bundle-analyzer 可以扫描 bundle 同时构建一个查看内部的可视化窗口。使用这个可视化工具找到过大或者不必要的依赖。
使用这个分析器，需要安装webpack-bundle-analyzer包：
npm install webpack-bundle-analyzer --save-dev
在 config 中增加插件：
// webpack.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerP
module.exports = {
plugins: [
new BundleAnalyzerPlugin(),
运行生产环境的 build 这个插件就会在浏览器中打开一个显示状态的页面。
默认情况下，这个页面会显示语法分析后的文件体积（在 bundle 出现的文件）。您可能想比较 gzip 的大小，因为这更接近实际用户的体验；使用左边的边栏来切换尺寸。
Note: 如果你使用 ，它可能在webpack-bundle-analyzer输出时合并一部分 module，使得报告小一些细节。如果你使用这个插件，在执行分析的时候需要禁用掉。
下面是报告中需要看什么：
大型依赖 为什么体积这么大？是否有更小的替代包（比如 Preact 替代 React）？用了全部代码（比如 Moment.js 包含大量的本地变量 ）？
重复依赖 是否在不同文件中看到相同的库？（使用_CommonsChunkPlugin_将他们移到一个通用文件内）亦或是在同一个库中 bundle 拥有多个版本？
相似依赖 是否存在有相似功能的相似库存在？（比如_moment_和_date-fns_ 或者 lodash 和 lodash-es）尽力汇总成一个。
同样的，也可以看看 Sean Larkin 的文章 。
Summing up
Use webpack-dashboard and bundlesize to stay tuned of how large your app is
Dig into what builds up the size with webpack-bundle-analyzer
Conclusion
总结一下：
剔除不必要的体积 把所有的都压缩，剔除无用代码，增加依赖是保持谨慎小心。
通过路由拆分代码 只在真正需要的时候才加载，其他的部分做来加载。
缓存代码 应用程序的某些部分更新频率低于其他部分，将这些部分拆分成文件，以便在必要时仅重新下载。
跟踪体积大小 使用
监控你的 app。每隔几个月重新检查一下你的应用的性能。
Webpack 不仅仅是一个帮助你更快创建 app 的工具。它还帮助使你的 app 成为
，你的应用拥有更好的体验以及自动化的填充工具就像根据环境给出建议。
不要忘记阅读
– 里面提供了大量的优化的信息。
多多练习 ！
没有账号？
第三方账号登录：