concepts

webpack是JS应用程序的静态模块打包工具。webpack在处理你的应用时，会递归的构建依赖项，这些依赖项包括你的应用程序所需要的所有模块，然后把这些模块打包到一个或多个bundles中。

一、Entry

entry point是项目的入口文件，告诉webpack从哪个模块开始构建内部依赖。进入入口文件后，webpack会直接或间接的找到其依赖的模块和库。

1、定义入口的方式有多种：

1）简写形式（string | array<string>）

module.exports = {
  entry: './path/to/my/entry/file.js'
}

module.exports = {
  entry: {
    main: './path/to/my/entry/file.js'
  }
}

上面的写法实际上是下面写法的简写形式

multi-main entry: entry是一个存放文件路径的数组，当你需要将多个依赖文件一起注入并将它们的依赖关系打包成一个chunk时，可以使用这种方式。

2）对象形式（{ [entryChunkName]: string|array<string> }）

const config = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
}

2、应用场景

1）分离app和vendor入口

const config = {
  entry: {
    app: './src/app.js',
    vendors: './src/vendors.js'
  }
}

这种形式告诉webpack从app.js和vendors.js开始创建分离的相互独立的依赖。这在单页面应用中很常用。这种设置允许你利用CommonsChunkPlugin将应用中任何vendor的引用抽离到vendor bundle. 这样在你的应用程序bundle中就没有vendor代码。

2）多页面应用

const config = {
  entry: {
    pageOne: './src/pageOne/index.js',
    pageTwo: './src/pageTwo/index.js',
    pageThree: './src/pageThree/index.js'
  }
};

这种设置方式告诉webpack我们有3个分离的依赖项。在多页面应用中，服务器需要获取新的HTML文档，页面重新加载新的文档和文件需要重新下载，这样我们就可以使用CommonsChunkPlugin将页面间共享的代码提取打包。

黄金条例：每个HTML文档使用一个入口。

二、Output

output属性告诉webpack打包文件的输出位置和名字。 output是一个对象，一般需要文件名（filename）和输出路径(path);

const path = require('path');

module.exports = {
  entry: './path/to/my/entry/file.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'my-first-webpack.bundle.js'
  }
};

1、多入口文件

当你的设置会有多个chunk（比如多个入口文件或者使用类似CommonsChunkPlugin）时使用，但你需要保证每个文件都有唯一的名字。

{
  entry: {
    app: './src/app.js',
    search: './src/search.js'
  },
  output: {
    filename: '[name].js',
    path: __dirname + '/dist'
  }
}

2、publicPath

当你将应用所需文件存放在CDN或者hash时

output: {
  path: "/home/proj/cdn/assets/[hash]",
  publicPath: "http://cdn.example.com/assets/[hash]/"
}

如果编译时不确定最终的publicPath,这个值可以设为空白或者不设置，然后在入口文件中使用__webpack_public_path__动态设置。

__webpack_public_path__ = myRuntimePublicPath

// rest of your application entry

三、Loaders

loaders可以帮助webpack处理更多类型的文件，不仅限于javascript（webpack自身只能处理JS）。loaders会将各种类型的文件转化为webpack能处理的合法模块。

1、使用方式

1） 配置文件

const path = require('path');

module.exports = {
  entry: './path/file.js',
  output:{
    path: path.resolve(__dirname,'dist'),
    filename:'bundle.js',
  },
  modules:{
    rules: [
      {test: /\.txt$/, use: 'raw-loader'}，
      {
        test: /\.css$/,
        use: [
          { loader: 'style-loader' },
          {
            loader: 'css-loader',
            options: {
              modules: true
            }
          }
        ]
      }
     ]
   }
}

2）inline

import Styles from 'style-loader!css-loader?modules!./styles.css';

options可以通过query参数形式传递，比如?key=value&foo=bar，或者JSON对象形式，比如?{"key":"value","foo":"bar"}

3) CLI

webpack --module-bind jade-loader --module-bind 'css=style-loader!css-loader'

四、Plugins

plugins可以做更多的事情，可以优化和更小化打包文件，或者定义环境变量。

plugin是一个JS对象，有apply属性。apply属性会被webpack的编译器调用，允许进入整个编译周期。

function ConsoleLogOnBuildWebpackPlugin() {

};

ConsoleLogOnBuildWebpackPlugin.prototype.apply = function(compiler) {
  compiler.plugin('run', function(compiler, callback) {
    console.log("The webpack build process is starting!!!");

    callback();
  });
};

 plugins: [
    new webpack.optimize.UglifyJsPlugin(),
    new HtmlWebpackPlugin({template: './src/index.html'})
  ]

五、Module Resolution

resolver帮助webpack定位模块位置。依赖模块可能来自应用程序中的代码或者第三方库，resolver可以帮助webpack找到模块代码，这些模块代码通过require/import引入，并被打包到bundle中。

1、resolving rules

1）绝对路径

import "/home/me/file";

import "C:\\Users\\me\\file";

因为已经包含了文件绝对路径，所以不需要其他的resolution。

2）相对路径

import "../src/file1";
import "./file2";

在这种情况下，源文件所在文件夹将作为context directory，然后将这些相对路径加入到context路径中生成模块的绝对路径。

3）Module path

import "module";
import "module/lib/file";

resolve.modules下的所有文件夹都会被搜索。你可以使用resolve.alias创建原始Module 路径的别名。

一旦通过上面的规则解析出了路径，resolve会检查该路径指向的是一个文件还是一个文件夹。

如果是文件：

该路径带有文件扩展名，那么文件直接被打包；否则，使用resolve.extensions解析出文件扩展名。

如果指向的是文件夹：

文件夹包含package.json文件，package.json中出现的第一项resolve.mainFields配置项中的文件决定最终的文件路径。如果文件夹中没有package.json文件，或者main fields中没有返回一个合法的路径，依次匹配resolve.mainFields配置项中指定的文件名，看是否找到匹配的文件路径。至于文件扩展名，仍然使用resolve.extensions来解析。

2、resolving loaders

3、caching

每个文件系统都是被缓存的，因此对一个文件的多个平行或者一系列请求会很快。在watch mode，只有修改过的文件会从缓存中删去。如果watch mode被关闭，那么缓存会在每次编译前清除。

六、Targets

因为JS可以用在服务端和浏览器端，你可以在webpack配置文件中配置部署目标。

1、使用

module.exports = {
  target: 'node'
};

在上面的例子中，使用node，webpack会编译一个类似nodejs的环境。target默认设置为web

2、multiple target

虽然webpack不支持给target传多个字符串，但是可以构建两个独立的配置来创建同构的库

var path = require('path');
var serverConfig = {
  target: 'node',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.node.js'
  }
  //…
};

var clientConfig = {
  target: 'web', // <=== can be omitted as default is 'web'
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.js'
  }
  //…
};

module.exports = [ serverConfig, clientConfig ];

这样会在你的dist文件夹下生成lib.js和lib.node.js两个文件。

https://github.com/TheLarkInn/compare-webpack-target-bundles

七、manifest

基本上在一个基于webpack的应用中，会出现三种类型的code:

• 应用源代码
• 第三方库或者源代码依赖的vendor code
• 联系各个模块的runtime 和 manifest

1、 Runtime

当你的应用在浏览器中运行时，runtime和manifest数据基本上是webpack联系你的模块化应用所需的所有code。它包含你的模块之间交互时，链接各个模块所需要的加载和解析逻辑。这包括了连接已经加载到浏览器中的模块，以及延迟加载的模块。

2、manifest

那么当你的应用以index.html文件在浏览器中运行时，那些bundles和其他的文件是什么样的呢？src目录下你写的代码都没有了，那么webpack是怎么处理modules之间的交互的呢？这就是manifest data用到的地方。。。

当编译器进入，解析并映射你的应用时，会一直关注你的modules。这些数据集合就是manifest，当这些modules bundled并且加载进浏览器时，runtime就会利用manifest来解析和加载modules。不管你用的是什么模块语言，import和require都会变为指向module identifiers的__webpack_require__方法。使用manifest中的数据，runtime可以找到这些identifiers后的module位置。

3、problem

这些内容平时一般都用不到，但是如果你想要使用浏览器缓存优化你的应用性能，就需要知道上面这些概念了。

将bundle文件名哈希表示，你可以告诉浏览器文件内容改变了，缓存已经没用了。但如果你这样做，你会发现，有时候文件内容没变，文件名的哈希表示也会变化。这就是因为runtime和manifest在每次构建时都会改变。

八、Hot Module Replacement

应用程序在运行时不需要重新加载页面，HMR就可以修改，添加和删除modules。这在几个方面加速开发过程：

• 保存应用在重新加载时会丢失的状态；
• 只更新改变的内容，节约宝贵的开发时间
• 更快的调整样式，几乎可以和浏览器开发者模式中调整样式一样快速生效

How it works

1、in the application

1）应用程序要求HMR runtime检查更新

2）runtime异步下载更新并通知应用程序

3）应用程序要求runtime应用更新

4）runtime同步应用更新

设置HMR，上面的步骤就会自动发生处理，或者也可以通过用户的交互来更新

2、in the compiler

除了更新普通的文件，编译器还需要发出更新信号，来允许从旧的版本更新到新的版本。这个更新包括两个部分：

• 更新后的manifest(JSON)
• 一个或多个更新后的chunks（JS）

manifest包含新的编译hash和所有更新后的chunks清单。每一个这种chunks包含所有更新过的modules 的新code（或者是一个flag表示module被删除）。

编译器会确保在这些构建中module id和chunk id一致，并将这些ID保存在内存中或者JSON文件中。

3、in a module

HMR只会影响包含HMR code的modules。比如style-loader，它实现了HMR接口，当从HMR接收到更新，会用新的样式替换旧的样式。

同样的，当在一个module实现HMR接口时，你可以根据module是否更新来决定接下来应该做什么。但是，在大多数情况下，不需要强制在每个module中写HMR code。如果一个module没有HMR处理机制，更新会冒泡。这意味着，一个单独的处理器可以更新整个module tree。如果一个单独的module被更新了，那么所有依赖项都会重新加载。

4、in the runtime

对于module system runtime，会有额外的代码来追踪module的parents和children。在管理方面，runtime支持两个方法：check和apply。

check向更新的manifest发送HTTP请求。如果请求失败，表示没有可用更新。如果成功，会对比更新后的chunks清单和当前已加载chunks清单。对于每个已加载chunk，相应的更新chunk会被下载。所有module更新都保存在runtime。当所有更新的chunks被下载下来，并且已经准备应用更新，runtime会把状态调整为ready状态。

apply方法将所有更新modules标志为无效。对于每一个无效module，在module或者他的parents处需要有一个更新处理程序。否则，无效标志会向上冒泡，将Parents也标志为无效。冒泡会持续冒到应用程序的入口或者到达一个有更新处理程序的module。如果从entry point开始冒泡，那么进程失败。

然后所有无效modules通过卸载程序被卸载。当前hash被更新，所有accept handlers被调用。runtime切换回idle状态，一切回归正常。