资讯专栏INFORMATION COLUMN

webpack配置

Doyle / 1202人阅读

摘要:配置无入口的在输出时的文件名称。配置发布到线上资源的前缀,为类型。则是用于配置这个异步插入的标签的值。配置以何种方式导出库。是字符串的枚举类型,支持以下配置。在为时,配置将没有意义。是可选配置项,类型需要是其中一个。

webpack配置

</>复制代码

  1. 查看所有文档页面:全栈开发,获取更多信息。

    原文链接:第2章 配置,原文广告模态框遮挡,阅读体验不好,所以整理成本文,方便查找。

配置 Webpack 的方式有两种:

通过一个 JavaScript 文件描述配置,例如使用 webpack.config.js 文件里的配置;

执行 Webpack 可执行文件时通过命令行参数传入,例如 webpack --devtool source-map

这两种方式可以相互搭配,例如执行 Webpack 时通过命令 webpack --config webpack-dev.config.js 指定配置文件,再去 webpack-dev.config.js 文件里描述部分配置。

按照配置所影响的功能来划分,可分为:

Entry 配置模块的入口;

Output 配置如何输出最终想要的代码;

Module 配置处理模块的规则;

Resolve 配置寻找模块的规则;

Plugins 配置扩展插件;

DevServer 配置 DevServer;

其它配置项 其它零散的配置项;

整体配置结构 整体地描述各配置项的结构;

多种配置类型 配置文件不止可以返回一个 Object,还有其他返回形式;

配置总结 寻找配置 Webpack 的规律,减少思维负担。

Entry

Webpack 在寻找相对路径的文件时会以 context 为根目录,context 默认为执行启动 Webpack 时所在的当前工作目录。

如果想改变 context 的默认配置,可以在配置文件里设置:

</>复制代码

  1. module.exports = {
  2. context: path.resolve(__dirname, "app")
  3. }

注意, context 必须是一个绝对路径的字符串。 除此之外,还可以通过在启动 Webpack 时带上参数 webpack --context 来设置 context。

Chunk 名称

Webpack 会为每个生成的 Chunk 取一个名称,Chunk 的名称和 Entry 的配置有关:

如果 entry 是一个 stringarray,就只会生成一个 Chunk,这时 Chunk 的名称是 main

如果 entry 是一个 object,就可能会出现多个 Chunk,这时 Chunk 的名称是 object 键值对里键的名称。

配置动态 Entry

假如项目里有多个页面需要为每个页面的入口配置一个 Entry ,但这些页面的数量可能会不断增长,则这时 Entry 的配置会受到到其他因素的影响导致不能写成静态的值。其解决方法是把 Entry 设置成一个函数去动态返回上面所说的配置,代码如下:

</>复制代码

  1. // 同步函数
  2. entry: () => {
  3. return {
  4. a:"./pages/a",
  5. b:"./pages/b",
  6. }
  7. };
  8. // 异步函数
  9. entry: () => {
  10. return new Promise((resolve)=>{
  11. resolve({
  12. a:"./pages/a",
  13. b:"./pages/b",
  14. });
  15. });
  16. };
Output

output 配置如何输出最终想要的代码。output 是一个 object,里面包含一系列配置项:

filename

output.filename 配置输出文件的名称,为 string 类型。 如果只有一个输出文件,则可以把它写成静态不变的:

</>复制代码

  1. filename: "bundle.js"

但是在有多个 Chunk 要输出时,就需要借助模版和变量了。前面说到 Webpack 会为每个 Chunk取一个名称,可以根据 Chunk 的名称来区分输出的文件名:

</>复制代码

  1. filename: "[name].js"

代码里的 [name] 代表用内置的 name 变量去替换[name],这时你可以把它看作一个字符串模块函数, 每个要输出的 Chunk 都会通过这个函数去拼接出输出的文件名称。

变量名 含义
id Chunk 的唯一标识,从0开始
name Chunk 的名称
hash Chunk 的唯一标识的 Hash 值
chunkhash Chunk 内容的 Hash 值

其中 hashchunkhash 的长度是可指定的,[hash:8] 代表取8位 Hash 值,默认是20位。

</>复制代码

  1. 注意 ExtractTextWebpackPlugin 插件是使用 contenthash 来代表哈希值而不是 chunkhash, 原因在于 ExtractTextWebpackPlugin 提取出来的内容是代码内容本身而不是由一组模块组成的 Chunk。
chunkFilename

output.chunkFilename 配置无入口的 Chunk 在输出时的文件名称。 chunkFilename 和上面的 filename 非常类似,但 chunkFilename 只用于指定在运行过程中生成的 Chunk 在输出时的文件名称。 常见的会在运行时生成 Chunk 场景有在使用 CommonChunkPlugin、使用 import("path/to/module") 动态加载等时。 chunkFilename 支持和 filename 一致的内置变量。

path

output.path 配置输出文件存放在本地的目录,必须是 string 类型的绝对路径。通常通过 Node.js 的 path 模块去获取绝对路径:

</>复制代码

  1. path: path.resolve(__dirname, "dist_[hash]")
publicPath

在复杂的项目里可能会有一些构建出的资源需要异步加载,加载这些异步资源需要对应的 URL 地址。

output.publicPath 配置发布到线上资源的 URL 前缀,为string 类型。 默认值是空字符串 "",即使用相对路径。

把构建出的资源文件上传到 CDN 服务上,以利于加快页面的打开速度。配置代码如下:

</>复制代码

  1. filename:"[name]_[chunkhash:8].js"
  2. publicPath: "https://cdn.example.com/assets/"

这时发布到线上的 HTML 在引入 JavaScript 文件时就需要:

</>复制代码

使用该配置项时要小心,稍有不慎将导致资源加载404错误。

output.pathoutput.publicPath 都支持字符串模版,内置变量只有一个:hash 代表一次编译操作的 Hash 值。

crossOriginLoading

Webpack 输出的部分代码块可能需要异步加载,而异步加载是通过 JSONP 方式实现的。 JSONP 的原理是动态地向 HTML 中插入一个 标签去加载异步资源。

output.crossOriginLoading 则是用于配置这个异步插入的标签的 crossorigin 值。

script 标签的 crossorigin 属性可以取以下值:

false(默认) 在加载此脚本资源时不会带上用户的 Cookies;

use-credentials 在加载此脚本资源时会带上用户的 Cookies。

通常用设置 crossorigin 来获取异步加载的脚本执行时的详细错误信息。

libraryTarget 和 library

当用 Webpack 去构建一个可以被其他模块导入使用的库时需要用到它们。

output.libraryTarget 配置以何种方式导出库。

output.library 配置导出库的名称。

假如配置了 output.library="LibraryName",则输出和使用的代码如下:

</>复制代码

  1. // Webpack 输出的代码
  2. var LibraryName = lib_code;
  3. // 使用库的方法
  4. LibraryName.doSomething();

假如 output.library 为空,则将直接输出:lib_code

</>复制代码

  1. 其中 lib_code 代指导出库的代码内容,是有返回值的一个自执行函数。

它们通常搭配在一起使用。

output.libraryTarget 是字符串的枚举类型,支持以下配置。

var (默认)

编写的库将通过 var 被赋值给通过 library 指定名称的变量。

commonjs

编写的库将通过 CommonJS2 规范导出,输出和使用的代码如下:

</>复制代码

  1. // Webpack 输出的代码
  2. module.exports = lib_code;
  3. // 使用库的方法
  4. require("library-name-in-npm").doSomething();

</>复制代码

  1. CommonJS2 和 CommonJS 规范很相似,差别在于 CommonJS 只能用 exports 导出,而 CommonJS2 在 CommonJS 的基础上增加了 module.exports 的导出方式。

output.libraryTarget 为 commonjs2 时,配置 output.library 将没有意义。

this

编写的库将通过 this 被赋值给通过 library 指定的名称,输出和使用的代码如下:

// Webpack 输出的代码
this["LibraryName"] = lib_code;

// 使用库的方法
this.LibraryName.doSomething();

window

编写的库将通过 window 被赋值给通过 library 指定的名称,即把库挂载到 window 上,输出和使用的代码如下:

</>复制代码

  1. // Webpack 输出的代码
  2. window["LibraryName"] = lib_code;
  3. // 使用库的方法
  4. window.LibraryName.doSomething();
global

编写的库将通过 global 被赋值给通过 library 指定的名称,即把库挂载到 global 上,输出和使用的代码如下:

</>复制代码

  1. // Webpack 输出的代码
  2. global["LibraryName"] = lib_code;
  3. // 使用库的方法
  4. global.LibraryName.doSomething();
libraryExport

output.libraryExport 配置要导出的模块中哪些子模块需要被导出。 它只有在 output.libraryTarget 被设置成 commonjs 或者 commonjs2 时使用才有意义。

假如要导出的模块源代码是:

</>复制代码

  1. export const a=1;
  2. export default b=2;

现在想让构建输出的代码只导出其中的 a,可以把 output.libraryExport 设置成 a,那么构建输出的代码和使用方法将变成如下:

</>复制代码

  1. // Webpack 输出的代码
  2. module.exports = lib_code["a"];
  3. // 使用库的方法
  4. require("library-name-in-npm")===1;
Module 配置 Loader

rules 配置模块的读取和解析规则,通常用来配置 Loader。其类型是一个数组,数组里每一项都描述了如何去处理部分文件。 配置一项 rules 时大致通过以下方式:

条件匹配:通过 testincludeexclude 三个配置项来命中 Loader 要应用规则的文件。

应用规则:对选中后的文件通过 use 配置项来应用 Loader,可以只应用一个 Loader 或者按照从后往前的顺序应用一组 Loader,同时还可以分别给 Loader 传入参数。

重置顺序:一组 Loader 的执行顺序默认是从右到左执行,通过 enforce 选项可以让其中一个 Loader 的执行顺序放到最前或者最后。

</>复制代码

  1. module: {
  2. rules: [
  3. {
  4. // 命中 JavaScript 文件
  5. test: /.js$/,
  6. // 用 babel-loader 转换 JavaScript 文件
  7. // ?cacheDirectory 表示传给 babel-loader 的参数,用于缓存 babel 编译结果加快重新编译速度
  8. use: ["babel-loader?cacheDirectory"],
  9. // 只命中src目录里的js文件,加快 Webpack 搜索速度
  10. include: path.resolve(__dirname, "src")
  11. },
  12. {
  13. // 命中 SCSS 文件
  14. test: /.scss$/,
  15. // 使用一组 Loader 去处理 SCSS 文件。
  16. // 处理顺序为从后到前,即先交给 sass-loader 处理,再把结果交给 css-loader 最后再给 style-loader。
  17. use: ["style-loader", "css-loader", "sass-loader"],
  18. // 排除 node_modules 目录下的文件
  19. exclude: path.resolve(__dirname, "node_modules"),
  20. },
  21. {
  22. // 对非文本文件采用 file-loader 加载
  23. test: /.(gif|png|jpe?g|eot|woff|ttf|svg|pdf)$/,
  24. use: ["file-loader"],
  25. },
  26. ]
  27. }

在 Loader 需要传入很多参数时,你还可以通过一个 Object 来描述,例如在上面的 babel-loader 配置中有如下代码:

</>复制代码

  1. use: [
  2. {
  3. loader:"babel-loader",
  4. options:{
  5. cacheDirectory:true,
  6. },
  7. // enforce:"post" 的含义是把该 Loader 的执行顺序放到最后
  8. // enforce 的值还可以是 pre,代表把 Loader 的执行顺序放到最前面
  9. enforce:"post"
  10. },
  11. // 省略其它 Loader
  12. ]

上面的例子中 test include exclude 这三个命中文件的配置项只传入了一个字符串或正则,其实它们还都支持数组类型,使用如下:

</>复制代码

  1. {
  2. test:[
  3. /.jsx?$/,
  4. /.tsx?$/
  5. ],
  6. include:[
  7. path.resolve(__dirname, "src"),
  8. path.resolve(__dirname, "tests"),
  9. ],
  10. exclude:[
  11. path.resolve(__dirname, "node_modules"),
  12. path.resolve(__dirname, "bower_modules"),
  13. ]
  14. }

数组里的每项之间是的关系,即文件路径符合数组中的任何一个条件就会被命中。

noParse

noParse 配置项可以让 Webpack 忽略对部分没采用模块化的文件的递归解析和处理,这样做的好处是能提高构建性能。 原因是一些库例如 jQuery 、ChartJS 它们庞大又没有采用模块化标准,让 Webpack 去解析这些文件耗时又没有意义。

noParse 是可选配置项,类型需要是 RegExp[RegExp]function 其中一个。

例如想要忽略掉 jQuery 、ChartJS,可以使用如下代码:

</>复制代码

  1. // 使用正则表达式
  2. noParse: /jquery|chartjs/
  3. // 使用函数,从 Webpack 3.0.0 开始支持
  4. noParse: (content)=> {
  5. // content 代表一个模块的文件路径
  6. // 返回 true or false
  7. return /jquery|chartjs/.test(content);
  8. }

</>复制代码

  1. 注意被忽略掉的文件里不应该包含 importrequiredefine 等模块化语句,不然会导致构建出的代码中包含无法在浏览器环境下执行的模块化语句。
parser

因为 Webpack 是以模块化的 JavaScript 文件为入口,所以内置了对模块化 JavaScript 的解析功能,支持 AMDCommonJSSystemJSES6

parser 属性可以更细粒度的配置哪些模块语法要解析哪些不解析,和 noParse 配置项的区别在于 parser 可以精确到语法层面, 而 noParse 只能控制哪些文件不被解析。 parser 使用如下:

</>复制代码

  1. module: {
  2. rules: [
  3. {
  4. test: /.js$/,
  5. use: ["babel-loader"],
  6. parser: {
  7. amd: false, // 禁用 AMD
  8. commonjs: false, // 禁用 CommonJS
  9. system: false, // 禁用 SystemJS
  10. harmony: false, // 禁用 ES6 import/export
  11. requireInclude: false, // 禁用 require.include
  12. requireEnsure: false, // 禁用 require.ensure
  13. requireContext: false, // 禁用 require.context
  14. browserify: false, // 禁用 browserify
  15. requireJs: false, // 禁用 requirejs
  16. }
  17. },
  18. ]
  19. }
Resolve

Webpack 在启动后会从配置的入口模块出发找出所有依赖的模块,Resolve 配置 Webpack 如何寻找模块所对应的文件。 Webpack 内置 JavaScript 模块化语法解析功能,默认会采用模块化标准里约定好的规则去寻找,但你也可以根据自己的需要修改默认的规则。

alias

resolve.alias 配置项通过别名来把原导入路径映射成一个新的导入路径。例如使用以下配置:

</>复制代码

  1. // Webpack alias 配置
  2. resolve:{
  3. alias:{
  4. components: "./src/components/"
  5. }
  6. }

当你通过 import Button from "components/button" 导入时,实际上被 alias 等价替换成了 import Button from "./src/components/button"

以上 alias 配置的含义是把导入语句里的 components 关键字替换成 ./src/components/

这样做可能会命中太多的导入语句,alias 还支持 $ 符号来缩小范围到只命中以关键字结尾的导入语句:

</>复制代码

  1. resolve:{
  2. alias:{
  3. "react$": "/path/to/react.min.js"
  4. }
  5. }

react$ 只会命中以 react 结尾的导入语句,即只会把 import "react" 关键字替换成 import "/path/to/react.min.js"

mainFields

有一些第三方模块会针对不同环境提供几分代码。 例如分别提供采用 ES5 和 ES6 的2份代码,这2份代码的位置写在 package.json 文件里,如下:

</>复制代码

  1. {
  2. "jsnext:main": "es/index.js",// 采用 ES6 语法的代码入口文件
  3. "main": "lib/index.js" // 采用 ES5 语法的代码入口文件
  4. }

Webpack 会根据 mainFields 的配置去决定优先采用哪份代码,mainFields 默认如下:

</>复制代码

  1. mainFields: ["browser", "main"]

Webpack 会按照数组里的顺序去 package.json 文件里寻找,只会使用找到的第一个。

假如你想优先采用 ES6 的那份代码,可以这样配置:

</>复制代码

  1. mainFields: ["jsnext:main", "browser", "main"]
extensions

在导入语句没带文件后缀时,Webpack 会自动带上后缀后去尝试访问文件是否存在。 resolve.extensions 用于配置在尝试过程中用到的后缀列表,默认是:

</>复制代码

  1. extensions: [".js", ".json"]
modules

resolve.modules 配置 Webpack 去哪些目录下寻找第三方模块,默认是只会去 node_modules 目录下寻找。

有时你的项目里会有一些模块会大量被其它模块依赖和导入,由于其它模块的位置分布不定,针对不同的文件都要去计算被导入模块文件的相对路径, 这个路径有时候会很长,就像这样 import "../../../components/button" 这时你可以利用 modules 配置项优化,假如那些被大量导入的模块都在 ./src/components 目录下,把 modules 配置成:

</>复制代码

  1. modules:["./src/components","node_modules"]

后,你可以简单通过 import "button" 导入。

descriptionFiles

resolve.descriptionFiles 配置描述第三方模块的文件名称,也就是 package.json 文件。默认如下:

</>复制代码

  1. descriptionFiles: ["package.json"]
enforceExtension

resolve.enforceExtension 如果配置为 true 所有导入语句都必须要带文件后缀, 例如开启前 import "./foo" 能正常工作,开启后就必须写成 import "./foo.js"

enforceModuleExtension

enforceModuleExtensionenforceExtension 作用类似,但 enforceModuleExtension 只对 node_modules 下的模块生效。

enforceModuleExtension 通常搭配 enforceExtension 使用,在 enforceExtension:true 时,因为安装的第三方模块中大多数导入语句没带文件后缀, 所以这时通过配置 enforceModuleExtension:false 来兼容第三方模块。

Plugins

Plugin 用于扩展 Webpack 功能,各种各样的 Plugin 几乎让 Webpack 可以做任何构建相关的事情。

配置 Plugin

Plugin 的配置很简单,plugins 配置项接受一个数组,数组里每一项都是一个要使用的 Plugin 的实例,Plugin 需要的参数通过构造函数传入。

</>复制代码

  1. const CommonsChunkPlugin = require("webpack/lib/optimize/CommonsChunkPlugin");
  2. module.exports = {
  3. plugins: [
  4. // 所有页面都会用到的公共代码提取到 common 代码块中
  5. new CommonsChunkPlugin({
  6. name: "common",
  7. chunks: ["a", "b"]
  8. }),
  9. ]
  10. };

使用 Plugin 的难点在于掌握 Plugin 本身提供的配置项,而不是如何在 Webpack 中接入 Plugin。

DevServer

要配置 DevServer ,除了在配置文件里通过 devServer 传入参数外,还可以通过命令行参数传入。 注意只有在通过 DevServer 去启动 Webpack 时配置文件里 devServer 才会生效,因为这些参数所对应的功能都是 DevServer 提供的,Webpack 本身并不认识 devServer 配置项。

hot

devServer.hot 配置是否启用模块热替换功能。

DevServer 默认的行为是在发现源代码被更新后会通过自动刷新整个页面来做到实时预览,开启模块热替换功能后将在不刷新整个页面的情况下通过用新模块替换老模块来做到实时预览。

inline

DevServer 的实时预览功能依赖一个注入到页面里的代理客户端去接受来自 DevServer 的命令和负责刷新网页的工作。

devServer.inline 用于配置是否自动注入这个代理客户端到将运行在页面里的 Chunk 里去,默认是会自动注入。 DevServer 会根据你是否开启 inline 来调整它的自动刷新策略:

如果开启 inline,DevServer 会在构建完变化后的代码时通过代理客户端控制网页刷新。

如果关闭 inline,DevServer 将无法直接控制要开发的网页。这时它会通过 iframe 的方式去运行要开发的网页,当构建完变化后的代码时通过刷新 iframe 来实现实时预览。

如果你想使用 DevServer 去自动刷新网页实现实时预览,最方便的方法是直接开启 inline

historyApiFallback

devServer.historyApiFallback 用于方便的开发使用了 HTML5 History API 的单页应用。

这类单页应用要求服务器在针对任何命中的路由时都返回一个对应的 HTML 文件,例如在访问 http://localhost/userhttp://localhost/home 时都返回 index.html 文件, 浏览器端的 JavaScript 代码会从 URL 里解析出当前页面的状态,显示出对应的界面。

配置 historyApiFallback 最简单的做法是:

</>复制代码

  1. historyApiFallback: true

这会导致任何请求都会返回 index.html 文件,这只能用于只有一个 HTML 文件的应用。

如果你的应用由多个单页应用组成,这就需要 DevServer 根据不同的请求来返回不同的 HTML 文件,配置如下:

</>复制代码

  1. historyApiFallback: {
  2. // 使用正则匹配命中路由
  3. rewrites: [
  4. // /user 开头的都返回 user.html
  5. { from: /^/user/, to: "/user.html" },
  6. { from: /^/game/, to: "/game.html" },
  7. // 其它的都返回 index.html
  8. { from: /./, to: "/index.html" },
  9. ]
  10. }
contentBase

devServer.contentBase 配置 DevServer HTTP 服务器的文件根目录。 默认情况下为当前执行目录,通常是项目根目录,所有一般情况下你不必设置它,除非你有额外的文件需要被 DevServer 服务。 例如你想把项目根目录下的 public 目录设置成 DevServer 服务器的文件根目录,你可以这样配置:

</>复制代码

  1. devServer:{
  2. contentBase: path.join(__dirname, "public")
  3. }

这里需要指出可能会让你疑惑的地方,DevServer 服务器通过 HTTP 服务暴露出的文件分为两类:

暴露本地文件。

暴露 Webpack 构建出的结果,由于构建出的结果交给了 DevServer,所以你在使用了 DevServer 时在本地找不到构建出的文件。

contentBase 只能用来配置暴露本地文件的规则,你可以通过 contentBase:false 来关闭暴露本地文件。

headers

devServer.headers 配置项可以在 HTTP 响应中注入一些 HTTP 响应头,使用如下:

</>复制代码

  1. devServer:{
  2. headers: {
  3. "X-foo":"bar"
  4. }
  5. }
host

devServer.host 配置项用于配置 DevServer 服务监听的地址。

例如你想要局域网中的其它设备访问你本地的服务,可以在启动 DevServer 时带上 --host 0.0.0.0host 的默认值是 127.0.0.1 即只有本地可以访问 DevServer 的 HTTP 服务。

port

devServer.port 配置项用于配置 DevServer 服务监听的端口,默认使用 8080 端口。 如果 8080 端口已经被其它程序占有就使用 8081,如果 8081 还是被占用就使用 8082,以此类推。

allowedHosts

devServer.allowedHosts 配置一个白名单列表,只有 HTTP 请求的 HOST 在列表里才正常返回,使用如下:

</>复制代码

  1. allowedHosts: [
  2. // 匹配单个域名
  3. "host.com",
  4. "sub.host.com",
  5. // host2.com 和所有的子域名 *.host2.com 都将匹配
  6. ".host2.com"
  7. ]
disableHostCheck

devServer.disableHostCheck 配置项用于配置是否关闭用于 DNS 重绑定的 HTTP 请求的 HOST 检查。

DevServer 默认只接受来自本地的请求,关闭后可以接受来自任何 HOST 的请求。 它通常用于搭配 --host 0.0.0.0 使用,因为你想要其它设备访问你本地的服务,但访问时是直接通过 IP 地址访问而不是 HOST 访问,所以需要关闭 HOST 检查。

https

DevServer 默认使用 HTTP 协议服务,它也能通过 HTTPS 协议服务。 有些情况下你必须使用 HTTPS,例如 HTTP2 和 Service Worker 就必须运行在 HTTPS 之上。 要切换成 HTTPS 服务,最简单的方式是:

</>复制代码

  1. devServer:{
  2. https: true
  3. }

DevServer 会自动的为你生成一份 HTTPS 证书。

如果你想用自己的证书可以这样配置:

</>复制代码

  1. devServer:{
  2. https: {
  3. key: fs.readFileSync("path/to/server.key"),
  4. cert: fs.readFileSync("path/to/server.crt"),
  5. ca: fs.readFileSync("path/to/ca.pem")
  6. }
  7. }
clientLogLevel

devServer.clientLogLevel 配置在客户端的日志等级,这会影响到你在浏览器开发者工具控制台里看到的日志内容。

clientLogLevel枚举类型,可取如下之一的值 none | error | warning | info。 默认为 info 级别,即输出所有类型的日志,设置成 none 可以不输出任何日志。

compress

devServer.compress 配置是否启用 gzip 压缩。boolean 为类型,默认为 false

open

devServer.open 用于在 DevServer 启动且第一次构建完时自动用你系统上默认的浏览器去打开要开发的网页。 同时还提供 devServer.openPage 配置项用于打开指定 URL 的网页。

其它配置项 Target

target 配置项可以让 Webpack 构建出针对不同运行环境的代码。 target 可以是以下之一:

target值 描述
web 针对浏览器 (默认),所有代码都集中在一个文件里
node 针对 Node.js,使用 require 语句加载 Chunk 代码
async-node 针对 Node.js,异步加载 Chunk 代码
webworker 针对 WebWorker
electron-main 针对 Electron 主线程
electron-renderer 针对 Electron 渲染线程

例如当你设置 target:"node" 时,源代码中导入 Node.js 原生模块的语句 require("fs") 将会被保留,fs 模块的内容不会打包进 Chunk 里。

Devtool

devtool 配置 Webpack 如何生成 Source Map,默认值是 false 即不生成 Source Map,想为构建出的代码生成 Source Map 以方便调试,可以这样配置:

</>复制代码

  1. module.export = {
  2. devtool: "source-map"
  3. }
Watch 和 WatchOptions

前面介绍过 Webpack 的监听模式,它支持监听文件更新,在文件发生变化时重新编译。在使用 Webpack 时监听模式默认是关闭的,想打开需要如下配置:

</>复制代码

  1. module.export = {
  2. watch: true
  3. }

在使用 DevServer 时,监听模式默认是开启的。

除此之外,Webpack 还提供了 watchOptions 配置项去更灵活的控制监听模式,使用如下:

</>复制代码

  1. module.export = {
  2. // 只有在开启监听模式时,watchOptions 才有意义
  3. // 默认为 false,也就是不开启
  4. watch: true,
  5. // 监听模式运行时的参数
  6. // 在开启监听模式时,才有意义
  7. watchOptions: {
  8. // 不监听的文件或文件夹,支持正则匹配
  9. // 默认为空
  10. ignored: /node_modules/,
  11. // 监听到变化发生后会等300ms再去执行动作,防止文件更新太快导致重新编译频率太高
  12. // 默认为 300ms
  13. aggregateTimeout: 300,
  14. // 判断文件是否发生变化是通过不停的去询问系统指定文件有没有变化实现的
  15. // 默认每1000豪秒去问1次
  16. poll: 1000
  17. }
  18. }
Externals

Externals 用来告诉 Webpack 要构建的代码中使用了哪些不用被打包的模块,也就是说这些模版是外部环境提供的,Webpack 在打包时可以忽略它们。

有些 JavaScript 运行环境可能内置了一些全局变量或者模块,例如在你的 HTML HEAD 标签里通过以下代码:

</>复制代码

引入 jQuery 后,全局变量 jQuery 就会被注入到网页的 JavaScript 运行环境里。

如果想在使用模块化的源代码里导入和使用 jQuery,可能需要这样:

</>复制代码

  1. import $ from "jquery";
  2. $(".my-element");

构建后你会发现输出的 Chunk 里包含的 jQuery 库的内容,这导致 jQuery 库出现了2次,浪费加载流量,最好是 Chunk 里不会包含 jQuery 库的内容。

Externals 配置项就是为了解决这个问题。

通过 externals 可以告诉 Webpack JavaScript 运行环境已经内置了那些全局变量,针对这些全局变量不用打包进代码中而是直接使用全局变量。 要解决以上问题,可以这样配置 externals

</>复制代码

  1. module.export = {
  2. externals: {
  3. // 把导入语句里的 jquery 替换成运行环境里的全局变量 jQuery
  4. jquery: "jQuery"
  5. }
  6. }
ResolveLoader

ResolveLoader 用来告诉 Webpack 如何去寻找 Loader,因为在使用 Loader 时是通过其包名称去引用的, Webpack 需要根据配置的 Loader 包名去找到 Loader 的实际代码,以调用 Loader 去处理源文件。

ResolveLoader 的默认配置如下:

</>复制代码

  1. module.exports = {
  2. resolveLoader:{
  3. // 去哪个目录下寻找 Loader
  4. modules: ["node_modules"],
  5. // 入口文件的后缀
  6. extensions: [".js", ".json"],
  7. // 指明入口文件位置的字段
  8. mainFields: ["loader", "main"]
  9. }
  10. }

该配置项常用于加载本地的 Loader。

整体配置结构

之前的章节分别讲述了每个配置项的具体含义,但没有描述它们所处的位置和数据结构,下面通过一份代码来描述清楚:

</>复制代码

  1. const path = require("path");
  2. module.exports = {
  3. // entry 表示 入口,Webpack 执行构建的第一步将从 Entry 开始,可抽象成输入。
  4. // 类型可以是 string | object | array
  5. entry: "./app/entry", // 只有1个入口,入口只有1个文件
  6. entry: ["./app/entry1", "./app/entry2"], // 只有1个入口,入口有2个文件
  7. entry: { // 有2个入口
  8. a: "./app/entry-a",
  9. b: ["./app/entry-b1", "./app/entry-b2"]
  10. },
  11. // 如何输出结果:在 Webpack 经过一系列处理后,如何输出最终想要的代码。
  12. output: {
  13. // 输出文件存放的目录,必须是 string 类型的绝对路径。
  14. path: path.resolve(__dirname, "dist"),
  15. // 输出文件的名称
  16. filename: "bundle.js", // 完整的名称
  17. filename: "[name].js", // 当配置了多个 entry 时,通过名称模版为不同的 entry 生成不同的文件名称
  18. filename: "[chunkhash].js", // 根据文件内容 hash 值生成文件名称,用于浏览器长时间缓存文件
  19. // 发布到线上的所有资源的 URL 前缀,string 类型
  20. publicPath: "/assets/", // 放到指定目录下
  21. publicPath: "", // 放到根目录下
  22. publicPath: "https://cdn.example.com/", // 放到 CDN 上去
  23. // 导出库的名称,string 类型
  24. // 不填它时,默认输出格式是匿名的立即执行函数
  25. library: "MyLibrary",
  26. // 导出库的类型,枚举类型,默认是 var
  27. // 可以是 umd | umd2 | commonjs2 | commonjs | amd | this | var | assign | window | global | jsonp ,
  28. libraryTarget: "umd",
  29. // 是否包含有用的文件路径信息到生成的代码里去,boolean 类型
  30. pathinfo: true,
  31. // 附加 Chunk 的文件名称
  32. chunkFilename: "[id].js",
  33. chunkFilename: "[chunkhash].js",
  34. // JSONP 异步加载资源时的回调函数名称,需要和服务端搭配使用
  35. jsonpFunction: "myWebpackJsonp",
  36. // 生成的 Source Map 文件名称
  37. sourceMapFilename: "[file].map",
  38. // 浏览器开发者工具里显示的源码模块名称
  39. devtoolModuleFilenameTemplate: "webpack:///[resource-path]",
  40. // 异步加载跨域的资源时使用的方式
  41. crossOriginLoading: "use-credentials",
  42. crossOriginLoading: "anonymous",
  43. crossOriginLoading: false,
  44. },
  45. // 配置模块相关
  46. module: {
  47. rules: [ // 配置 Loader
  48. {
  49. test: /.jsx?$/, // 正则匹配命中要使用 Loader 的文件
  50. include: [ // 只会命中这里面的文件
  51. path.resolve(__dirname, "app")
  52. ],
  53. exclude: [ // 忽略这里面的文件
  54. path.resolve(__dirname, "app/demo-files")
  55. ],
  56. use: [ // 使用那些 Loader,有先后次序,从后往前执行
  57. "style-loader", // 直接使用 Loader 的名称
  58. {
  59. loader: "css-loader",
  60. options: { // 给 html-loader 传一些参数
  61. }
  62. }
  63. ]
  64. },
  65. ],
  66. noParse: [ // 不用解析和处理的模块
  67. /special-library.js$/ // 用正则匹配
  68. ],
  69. },
  70. // 配置插件
  71. plugins: [],
  72. // 配置寻找模块的规则
  73. resolve: {
  74. modules: [ // 寻找模块的根目录,array 类型,默认以 node_modules 为根目录
  75. "node_modules",
  76. path.resolve(__dirname, "app")
  77. ],
  78. extensions: [".js", ".json", ".jsx", ".css"], // 模块的后缀名
  79. alias: { // 模块别名配置,用于映射模块
  80. //"module" 映射 "new-module",同样的 "module/path/file" 也会被映射成 "new-module/path/file"
  81. "module": "new-module",
  82. // 使用结尾符号 $ 后,把 "only-module" 映射成 "new-module"
  83. // 但是不像上面的,"module/path/file" 不会被映射成 "new-module/path/file"
  84. "only-module$": "new-module",
  85. },
  86. alias: [ // alias 还支持使用数组来更详细的配置
  87. {
  88. name: "module", // 老的模块
  89. alias: "new-module", // 新的模块
  90. // 是否是只映射模块,如果是 true 只有 "module" 会被映射,如果是 false "module/inner/path" 也会被映射
  91. onlyModule: true,
  92. }
  93. ],
  94. symlinks: true, // 是否跟随文件软链接去搜寻模块的路径
  95. descriptionFiles: ["package.json"], // 模块的描述文件
  96. mainFields: ["main"], // 模块的描述文件里的描述入口的文件的字段名称
  97. enforceExtension: false, // 是否强制导入语句必须要写明文件后缀
  98. },
  99. // 输出文件性能检查配置
  100. performance: {
  101. hints: "warning", // 有性能问题时输出警告
  102. hints: "error", // 有性能问题时输出错误
  103. hints: false, // 关闭性能检查
  104. maxAssetSize: 200000, // 最大文件大小 (单位 bytes)
  105. maxEntrypointSize: 400000, // 最大入口文件大小 (单位 bytes)
  106. assetFilter: function (assetFilename) { // 过滤要检查的文件
  107. return assetFilename.endsWith(".css") || assetFilename.endsWith(".js");
  108. }
  109. },
  110. devtool: "source-map", // 配置 source-map 类型
  111. context: __dirname, // Webpack 使用的根目录,string 类型必须是绝对路径
  112. // 配置输出代码的运行环境
  113. target: "web", // 浏览器,默认
  114. target: "webworker", // WebWorker
  115. target: "node", // Node.js,使用 `require` 语句加载 Chunk 代码
  116. target: "async-node", // Node.js,异步加载 Chunk 代码
  117. target: "node-webkit", // nw.js
  118. target: "electron-main", // electron, 主线程
  119. target: "electron-renderer", // electron, 渲染线程
  120. externals: { // 使用来自 JavaScript 运行环境提供的全局变量
  121. jquery: "jQuery"
  122. },
  123. stats: { // 控制台输出日志控制
  124. assets: true,
  125. colors: true,
  126. errors: true,
  127. errorDetails: true,
  128. hash: true,
  129. },
  130. devServer: { // DevServer 相关的配置
  131. proxy: { // 代理到后端服务接口
  132. "/api": "http://localhost:3000"
  133. },
  134. contentBase: path.join(__dirname, "public"), // 配置 DevServer HTTP 服务器的文件根目录
  135. compress: true, // 是否开启 gzip 压缩
  136. historyApiFallback: true, // 是否开发 HTML5 History API 网页
  137. hot: true, // 是否开启模块热替换功能
  138. https: false, // 是否开启 HTTPS 模式
  139. },
  140. profile: true, // 是否捕捉 Webpack 构建的性能信息,用于分析什么原因导致构建性能不佳
  141. cache: false, // 是否启用缓存提升构建速度
  142. watch: true, // 是否开始
  143. watchOptions: { // 监听模式选项
  144. // 不监听的文件或文件夹,支持正则匹配。默认为空
  145. ignored: /node_modules/,
  146. // 监听到变化发生后会等300ms再去执行动作,防止文件更新太快导致重新编译频率太高
  147. // 默认为300ms
  148. aggregateTimeout: 300,
  149. // 判断文件是否发生变化是不停的去询问系统指定文件有没有变化,默认每秒问 1000 次
  150. poll: 1000
  151. },
  152. };
多种配置类型

除了通过导出一个 Object 来描述 Webpack 所需的配置外,还有其它更灵活的方式,以简化不同场景的配置。

导出一个 Function

在大多数时候你需要从同一份源代码中构建出多份代码,例如一份用于开发时,一份用于发布到线上。

如果采用导出一个 Object 来描述 Webpack 所需的配置的方法,需要写两个文件。 一个用于开发环境,一个用于线上环境。再在启动时通过 webpack --config webpack.config.js 指定使用哪个配置文件。

采用导出一个 Function 的方式,能通过 JavaScript 灵活的控制配置,做到只写一个配置文件就能完成以上要求。

导出一个 Function 的使用方式如下:

</>复制代码

  1. const path = require("path");
  2. const UglifyJsPlugin = require("webpack/lib/optimize/UglifyJsPlugin");
  3. module.exports = function (env = {}, argv) {
  4. const plugins = [];
  5. const isProduction = env["production"];
  6. // 在生成环境才压缩
  7. if (isProduction) {
  8. plugins.push(
  9. // 压缩输出的 JS 代码
  10. new UglifyJsPlugin()
  11. )
  12. }
  13. return {
  14. plugins: plugins,
  15. // 在生成环境不输出 Source Map
  16. devtool: isProduction ? undefined : "source-map",
  17. };
  18. };

在运行 Webpack 时,会给这个函数传入2个参数,分别是:

env:当前运行时的 Webpack 专属环境变量,env 是一个 Object。读取时直接访问 Object 的属性,设置它需要在启动 Webpack 时带上参数。例如启动命令是 webpack --env.production --env.bao=foo 时,则 env 的值是 {"production":"true","bao":"foo"}

argv:代表在启动 Webpack 时所有通过命令行传入的参数,例如 --config、--env、--devtool,可以通过 webpack -h 列出所有 Webpack 支持的命令行参数。

就以上配置文件而言,在开发时执行命令 webpack 构建出方便调试的代码,在需要构建出发布到线上的代码时执行 webpack --env.production 构建出压缩的代码。

导出一个返回 Promise 的函数

在有些情况下你不能以同步的方式返回一个描述配置的 Object,Webpack 还支持导出一个返回 Promise 的函数,使用如下:

</>复制代码

  1. module.exports = function(env = {}, argv) {
  2. return new Promise((resolve, reject) => {
  3. setTimeout(() => {
  4. resolve({
  5. // ...
  6. })
  7. }, 5000)
  8. })
  9. }
导出多份配置

除了只导出一份配置外,Webpack 还支持导出一个数组,数组中可以包含每份配置,并且每份配置都会执行一遍构建。

使用如下:

</>复制代码

  1. module.exports = [
  2. // 采用 Object 描述的一份配置
  3. {
  4. // ...
  5. },
  6. // 采用函数描述的一份配置
  7. function() {
  8. return {
  9. // ...
  10. }
  11. },
  12. // 采用异步函数描述的一份配置
  13. function() {
  14. return Promise();
  15. }
  16. ]

以上配置会导致 Webpack 针对这三份配置执行三次不同的构建。

这特别适合于用 Webpack 构建一个要上传到 Npm 仓库的库,因为库中可能需要包含多种模块化格式的代码,例如 CommonJS、UMD。

配置总结

从前面的配置看来选项很多,Webpack 内置了很多功能。

你不必都记住它们,只需要大概明白 Webpack 原理和核心概念去判断选项大致属于哪个大模块下,再去查详细的使用文档。

通常你可用如下经验去判断如何配置 Webpack:

想让源文件加入到构建流程中去被 Webpack 控制,配置 entry

想自定义输出文件的位置和名称,配置 output

想自定义寻找依赖模块时的策略,配置 resolve

想自定义解析和转换文件的策略,配置 module,通常是配置 module.rules 里的 Loader。

其它的大部分需求可能要通过 Plugin 去实现,配置 plugin

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/95190.html

相关文章

  • TCM的webpack配置与常用插件

    摘要:中的配置热加载插件安装中的配置优化插件为组件分配,通过这个插件可以分析和优先考虑使用最多的模块,并为它们分配最小的压缩代码分离和文件 0 前言 本文是针对TCM项目所做的WebPack配置文件总结,主要概述了一些常用配置选项和插件使用,对以后的项目有指导意义。TCM的webpack配置文件包括webapck.config.base.js、webapck.config.dev.js、we...

    罗志环 评论0 收藏0
  • TCM的webpack配置与常用插件

    摘要:中的配置热加载插件安装中的配置优化插件为组件分配,通过这个插件可以分析和优先考虑使用最多的模块,并为它们分配最小的压缩代码分离和文件 0 前言 本文是针对TCM项目所做的WebPack配置文件总结,主要概述了一些常用配置选项和插件使用,对以后的项目有指导意义。TCM的webpack配置文件包括webapck.config.base.js、webapck.config.dev.js、we...

    张宪坤 评论0 收藏0
  • Webpack入门到精通(1)

    前言 什么是webpack 本质上,webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时,它会递归地构建一个依赖关系图(dependency graph),其中包含应用程序需要的每个模块,然后将所有这些模块打包成一个或多个 bundle。 webpack 有哪些功能(代码转换 文件优化 代码分割 模块合并 ...

    SunZhaopeng 评论0 收藏0
  • Webpack入门到精通(1)

    前言 什么是webpack 本质上,webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时,它会递归地构建一个依赖关系图(dependency graph),其中包含应用程序需要的每个模块,然后将所有这些模块打包成一个或多个 bundle。webpack 有哪些功能(代码转换 文件优化 代码分割 模块合并 自...

    wangbinke 评论0 收藏0
  • 基于webpack构建的angular 1.x 工程(一)webpack

    摘要:基于构建的工程一篇现在都已经出到的版本了,可我对它的认识还是停留在的版本。然后是写启动的命令行,也就是上面的这样写的意思是,当你输入你的命令名字就会让执行你对应命令的语句。我们首先把基本的配置引进来。 基于webpack构建的angular 1.x 工程(一)webpack篇   现在AngularJS都已经出到4.x的版本了,可我对它的认识还是停留在1.x的版本。   之前用它是为...

    Anleb 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<