webpack模块解析

前面的话

　　在web存在多种支持JavaScript模块化的工具(如requirejs和r.js)，这些工具各有优点和限制。webpack基于从这些系统得到的经验教训，并将模块的概念应用于项目中的任何文件。本文将详细介绍webpack的模块解析

 

模块

　　在模块化编程中，开发者将程序分解成离散功能块(discrete chunks of functionality)，并称之为模块

　　每一个模块具备比完整程序更小的接触面，使得校验、调试、测试垂手可得。 精心编写的模块提供了可靠的抽象和封装界限，使得应用程序中每一个模块都具备条理清楚的设计和明确的目的

　　Node.js从最一开始就支持模块化编程。对比Node.js模块，webpack模块可以以各类方式表达它们的依赖关系

ES2015 import 语句
CommonJS require() 语句
AMD define 和 require 语句
css/sass/less 文件中的 @import 语句。
样式(url(...))或 HTML 文件(<img src=...>)中的图片连接(image url)

　　[注意]webpack 1须要特定的loader来转换ES 2015 import，然而经过webpack 2能够开箱即用

【支持类型】

　　webpack经过loader能够支持各类语言和预处理器编写模块。loader描述了webpack如何处理非JavaScript(non-JavaScript) 模块，而且在bundle中引入这些依赖。 webpack 社区已经为各类流行语言和语言处理器构建了loader，包括：

CoffeeScript
TypeScript
ESNext (Babel)
Sass
Less
Stylus

　　总的来讲，webpack提供了可定制的、强大和丰富的API，容许任何技术栈使用webpack，保持了在开发、测试和生成流程中无侵入性(non-opinionated)

 

模块解析

　　resolver是一个库(library)，用于帮助找到模块的绝对路径。一个模块能够做为另外一个模块的依赖模块，而后被后者引用，以下：

import foo from 'path/to/module'
// 或者
require('path/to/module')

　　所依赖的模块能够是来自应用程序代码或第三方的库(library)。resolver帮助webpack找到bundle中须要引入的模块代码，这些代码在包含在每一个require/import语句中。当打包模块时，webpack使用enhanced-resolve来解析文件路径

【解析规则】

　　使用enhanced-resolve，webpack可以解析三种文件路径：

　　一、绝对路径

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

　　因为已经取得文件的绝对路径，所以不须要进一步再作解析

　　二、相对路径

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

　　在这种状况下，使用import或require的资源文件(resource file)所在的目录被认为是上下文目录(context directory)。在import/require中给定的相对路径，会添加此上下文路径(context path)，以产生模块的绝对路径(absolute path)

　　三、模块路径

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

　　模块将在resolve.modules中指定的全部目录内搜索。 能够替换初始模块路径，此替换路径经过使用resolve.alias配置选项来建立一个别名

　　一旦根据上述规则解析路径后，解析器(resolver)将检查路径是否指向文件或目录

　　若是路径指向一个文件：

　　　　a、若是路径具备文件扩展名，则被直接将文件打包

　　　　b、不然，将使用 [resolve.extensions] 选项做为文件扩展名来解析，此选项告诉解析器在解析中可以接受哪些扩展名（例如 .js, .jsx）

　　若是路径指向一个文件夹，则采起如下步骤找到具备正确扩展名的正确文件：

　　　　a、若是文件夹中包含 package.json 文件，则按照顺序查找 resolve.mainFields 配置选项中指定的字段。而且 package.json 中的第一个这样的字段肯定文件路径

　　　　b、若是package.json文件不存在或者package.json文件中的main字段没有返回一个有效路径，则按照顺序查找 esolve.mainFiles配置选项中指定的文件名，看是否能在import/require目录下匹配到一个存在的文件名

　　　　c、文件扩展名经过 resolve.extensions 选项采用相似的方法进行解析

　　webpack 根据构建目标(build target)为这些选项提供了合理的默认配置

【解析与缓存】

　　Loader解析遵循与文件解析器指定的规则相同的规则。resolveLoader 配置选项能够用来为 Loader 提供独立的解析规则。

　　每一个文件系统访问都被缓存，以便更快触发对同一文件的多个并行或穿行请求。在观察模式下，只有修改过的文件会从缓存中摘出。若是关闭观察模式，在每次编译前清理缓存

 

依赖图表

　　任什么时候候，一个文件依赖于另外一个文件，webpack就把此视为文件之间有依赖关系。这使得 webpack 能够接收非代码资源(non-code asset)（例如图像或 web 字体），而且能够把它们做为依赖提供给应用程序

　　webpack从命令行或配置文件中定义的一个模块列表开始，处理应用程序。 从这些入口起点开始，webpack 递归地构建一个依赖图表，这个依赖图表包含着应用程序所需的每一个模块，而后将全部这些模块打包为少许的bundle(一般只有一个 )可由浏览器加载

 

构建目标

　　由于服务器和浏览器代码均可以用JavaScript编写，因此webpack提供了多种构建目标(target)，能够在webpack配置中设置

【用法】

　　要设置target属性，只须要在webpack配置中设置target的值

//webpack.config.js
module.exports = {
  target: 'node'
};

　　在上面例子中，使用node webpack会编译为用于「类Node.js」环境（使用Node.js的require，而不是使用任意内置模块（如fs或path）来加载chunk）。

　　每一个target都有各类部署(deployment)/环境(environment)特定的附加项，以支持知足其需求

【多个Target】

　　尽管webpack不支持向target传入多个字符串，能够经过打包两份分离的配置来建立同构的库

//webpack.config.js
var path = require('path');
var serverConfig = {
  target: 'node',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.node.js'
  }
  //…
};
var clientConfig = {
  target: 'web', // <=== 默认是 'web'，可省略
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.js'
  }
  //…
};
module.exports = [ serverConfig, clientConfig ];

　　上面的例子将在的dist文件夹下建立lib.js和lib.node.js文件

 

模块热替换

　　模块热替换HMR(Hot Module Replacement)功能会在应用程序运行过程当中替换、添加或删除模块，而无需从新加载页面。这使得能够在独立模块变动后，无需刷新整个页面，就能够更新这些模块，极大地加速了开发时间

【站在App的角度】

　　一、app代码要求HMR runtime 检查更新

　　二、HMR runtime （异步）下载更新，而后通知 app 代码更新可用

　　三、app 代码要求 HMR runtime 应用更新

　　四、HMR runtime （异步）应用更新

　　能够设置 HMR，使此进程自动触发更新，或者能够选择要求在用户交互后进行更新

【站在编译器(webpack)的角度】

　　除了普通资源，编译器(compiler)须要发出 "update"，以容许更新以前的版本到新的版本。"update" 由两部分组成：一、待更新manifest (JSON)；二、一个或多个待更新chunk (JavaScript)；

　　manifest 包括新的编译 hash 和全部的待更新 chunk 目录。

　　每一个待更新 chunk 包括用于与全部被更新模块相对应 chunk 的代码（或一个 flag 用于代表模块要被移除）。

　　编译器确保模块 ID 和 chunk ID 在这些构建之间保持一致。一般将这些 ID 存储在内存中（例如，当使用 webpack-dev-server 时），可是也可能将它们存储在一个 JSON 文件中

【站在模块的角度】

　　HMR 是可选功能，只会影响包含 HMR 代码的模块。举个例子，经过 style-loader 为 style 样式追加补丁。 为了运行追加补丁，style-loader 实现了 HMR 接口；当它经过 HMR 接收到更新，它会使用新的样式替换旧的样式。

　　相似的，当在一个模块中实现了 HMR 接口，能够描述出当模块被更新后发生了什么。然而在多数状况下，不须要强制在每一个模块中写入 HMR 代码。若是一个模块没有 HMR 处理函数，更新就会冒泡。这意味着一个简单的处理函数可以对整个模块树(complete module tree)进行处理。若是在这个模块树中，一个单独的模块被更新，那么整个模块树都会被从新加载（只会从新加载，不会迁移）。

【站在HMR Runtime的角度】

　　对于模块系统的 runtime，附加的代码被发送到 parents 和 children 跟踪模块。

　　在管理方面，runtime 支持两个方法 check 和 apply。

　　一、check 发送 HTTP 请求来更新 manifest。若是请求失败，说明没有可用更新。若是请求成功，待更新 chunk 会和当前加载过的 chunk 进行比较。对每一个加载过的 chunk，会下载相对应的待更新 chunk。当全部待更新 chunk 完成下载，就会准备切换到 ready 状态。

　　二、apply 方法将全部被更新模块标记为无效。对于每一个无效模块，都须要在模块中有一个更新处理函数，或者在它的父级模块们中有更新处理函数。不然，无效标记冒泡，并将父级也标记为无效。每一个冒泡继续直到到达应用程序入口起点，或者到达带有更新处理函数的模块（以最早到达为准）。若是它从入口起点开始冒泡，则此过程失败。

　　以后，全部无效模块都被（经过 dispose 处理函数）处理和解除加载。而后更新当前 hash，而且调用全部 "accept" 处理函数。runtime 切换回闲置状态，一切照常继续

　　能够在开发过程当中将 HMR 做为 LiveReload 的替代。webpack-dev-server 支持热模式，在试图从新加载整个页面以前，热模式会尝试使用 HMR 来更新

　　一些 loader 已经生成可热更新的模块。例如，style-loader 可以置换出页面的样式表。对于这样的模块，不须要作任何特殊处理