打算系统的整理一下，webpack 的一些知识点，也是时候结合项目中使用的一些 案例，做一些总结了。

webpack系列 打算从 webpack核心功能 -> 常用扩展 -> CSS 工程化 -> JS 兼容性 -> 性能优化 这几个方面开始记录。

以及结合一些案例，方便大家阅读和实践，以备 开箱即用。

仓库地址：PantherVkin/webpack-note (github.com)

浏览器端的模块化

浏览器端实现模块化的问题

效率问题

精细的模块划分带来了更多的JS文件，更多的JS文件带来了更多的请求，降低了页面访问效率。

兼容性问题

浏览器目前仅支持ES6的模块化标准，并且还存在兼容性问题。

工具问题

浏览器不支持npm下载的第三方包。

这些仅仅是前端工程化的一个缩影。

当开发一个具有规模的程序，你将遇到非常多的非业务问题。

这些问题包括：执行效率、兼容性、代码的可维护性可扩展性、团队协作、测试等等等等，我们将这些问题称之为工程问题。

工程问题与业务无关，但它深刻的影响到开发进度，如果没有一个好的工具解决这些问题，将使得开发进度变得极其缓慢，同时也让开发者陷入技术的泥潭。

为什么node端，没有这些问题？

上面提到的问题，为什么在node端没有那么明显，反而到了浏览器端变得如此严重呢？

在node端，运行的JS文件在本地，因此可以本地读取文件，它的效率比浏览器远程传输文件高的多。

根本原因

在浏览器端，开发时态（devtime）和运行时态（runtime）的侧重点不一样。

这种差异在小项目中表现的并不明显，可是一旦项目形成规模，就越来越明显，如果不解决这些问题，前端项目形成规模只能是空谈。

开发时态，devtime

模块划分越细越好。

支持多种模块化标准。

支持npm或其他包管理器下载的模块。

能够解决其他工程化的问题。

运行时态，runtime

文件越少越好。

文件体积越小越好。

代码内容越乱越好。

所有浏览器都要兼容。

能够解决其他运行时的问题，主要是执行效率问题。

解决办法

既然开发时态和运行时态面临的局面有巨大的差异，因此，我们需要有一个工具，这个工具能够让开发者专心的在开发时态写代码，然后利用这个工具将开发时态编写的代码转换为运行时态需要的东西。

这样的工具，叫做构建工具，比如：webpack。

这样一来，开发者就可以专注于开发时态的代码结构，而不用担心运行时态遇到的问题了。

webpack的安装和使用

webpack 官网

webpack 中文

webpack简介

webpack是基于模块化的打包（构建）工具，它把一切视为模块。

它通过一个开发时态的入口模块为起点，分析出所有的依赖关系，然后经过一系列的过程（压缩、合并），最终生成运行时态的文件。

为前端工程化而生

webpack致力于解决前端工程化，特别是浏览器端工程化中遇到的问题，让开发者集中注意力编写业务代码，而把工程化过程中的问题全部交给webpack来处理。

简单易用

支持零配置，可以不用写任何一行额外的代码就使用webpack。

强大的生态

webpack是非常灵活、可以扩展的，webpack本身的功能并不多，但它提供了一些可以扩展其功能的机制，使得一些第三方库可以融于到webpack中。

基于nodejs

由于webpack在构建的过程中需要读取文件，因此它是运行在node环境中的。

基于模块化

webpack在构建过程中要分析依赖关系，方式是通过模块化导入语句进行分析的，它支持各种模块化标准，包括但不限于CommonJS、ES6 Module。

安装

webpack通过npm安装，它提供了两个包

webpack：核心包，包含了webpack构建过程中要用到的所有api

webpack-cli：提供一个简单的cli命令，它调用了webpack核心包的api，来完成构建过程

安装方式

全局安装

可以全局使用webpack命令，但是无法为不同项目对应不同的webpack版本。

本地安装：推荐

每个项目都使用自己的webpack版本进行构建。

$ npm i -D webpack webpack-cli

使用

npx webpack

运行项目本地安装的webpack。

默认情况下，webpack会以./src/index.js作为入口文件分析依赖关系，打包到./dist/main.js文件中。

控制打包结果的运行环境

--mode 选项可以控制webpack的打包结果的运行环境。

打包到开发环境：npx webpack --mode=development 。
打包到运行环境（默认值）：npx webpack --mode=production 。

打包结果分析【源码】

webpack-note/examples/1.1-编译结果分析 at master · PantherVkin/webpack-note (github.com)

配置文件

默认情况下，webpack会读取webpack.config.js文件作为配置文件，但也可以通过CLI参数--config来指定某个配置文件。

配置文件放在项目的根目录。

配置文件中通过CommonJS模块导出一个对象，对象中的各种属性对应不同的webpack配置。

基本配置

基本配置：

mode

编译模式，字符串，取值为development或production，指定编译结果代码运行的环境。

会影响webpack对编译结果代码格式的处理。

module.exports= {
    mode: 'development'
}

entry

入口，字符串（后续会详细讲解），指定入口文件

output

出口，对象（后续会详细讲解），指定编译结果文件

module.exports= {
    entry: "./src/main.js",
    output: {
        filename: "bundle.js"    
    }
}

devtool 配置

source map

什么是源码地图？

前端发展到现阶段，很多时候都不会直接运行源代码，可能需要对源代码进行合并、压缩、转换等操作，真正运行的是转换后的代码。

这就给调试带来了困难，因为当运行发生错误的时候，我们更加希望能看到源代码中的错误，而不是转换后代码的错误。

为了解决这一问题，chrome浏览器率先支持了source map，其他浏览器纷纷效仿，目前，几乎所有新版浏览器都支持了source map。

source map实际上是一个配置，配置中不仅记录了所有源码内容，还记录了和转换后的代码的对应关系。

浏览器处理source map的原理？

最佳实践：

source map 应在开发环境中使用

作为一种调试手段。

source map 不应该在生产环境中使用

source map 的文件一般较大，不仅会导致额外的网络传输，还容易暴露原始代码。即便要在生产环境中使用source map，用于调试真实的代码运行问题，也要做出一些处理规避网络传输和代码暴露的问题。

最佳实践

使用 webpack 编译后的代码难以调试，可以通过 devtool 配置来优化调试体验。

具体的配置：www.webpackjs.com/configurati…。

开发模式：

这些选项通常用于开发环境中。

eval

开发模式使用eval（默认使用）。

每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会非常快地构建。

缺点

由于会映射到转换后的代码，而不是映射到原始代码（没有从 loader 中获取 source map），所以不能正确的显示行数。

eval-source-map

每个模块使用 eval() 执行，并且 source map 转换为 DataUrl 后添加到 eval() 中。初始化 source map 时比较慢，但是会在重新构建时提供比较快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。它会生成用于开发环境的最佳品质的 source map。

base64 ，内嵌在main.js。

cheap-eval-source-map

类似 eval-source-map，每个模块使用 eval() 执行。这是 "cheap(低开销)" 的 source map，因为它没有生成列映射(column mapping)，只是映射行数。它会忽略源自 loader 的 source map，并且仅显示转译后的代码，就像 eval devtool。

cheap-module-eval-source-map

类似 cheap-eval-source-map，并且，在这种情况下，源自 loader 的 source map 会得到更好的处理结果。

然而，loader source map 会被简化为每行一个映射(mapping)。

生产环境：

这些选项通常用于生产环境中。

(none)（省略 devtool 选项）

不生成 source map。这是一个不错的选择。

source-map

整个 source map 作为一个单独的文件生成。它为 bundle 添加了一个引用注释，以便开发工具知道在哪里可以找到它。

你应该将你的服务器配置为，不允许普通用户访问 source map 文件！

hidden-source-map

与 source-map 相同，但不会为 bundle 添加引用注释。如果你只想 source map 映射那些源自错误报告的错误堆栈跟踪信息，但不想为浏览器开发工具暴露你的 source map，这个选项会很有用。

你不应将 source map 文件部署到 web 服务器。而是只将其用于错误报告工具。

nosources-source-map

创建的 source map 不包含 sourcesContent(源代码内容)。它可以用来映射客户端上的堆栈跟踪，而无须暴露所有的源代码。你可以将 source map 文件部署到 web 服务器。

这仍然会暴露反编译后的文件名和结构，但它不会暴露原始代码。

在使用 uglifyjs-webpack-plugin 时，你必须提供 sourceMap：true 选项来启用 source map 支持。

webpack 编译过程

webpack-note/examples/1.3-webpack编译过程 at master · PantherVkin/webpack-note (github.com)

出口和入口

出口 output

这里的出口是针对资源列表的文件名或路径的配置。

出口通过output进行配置。

var path = require('path')

// node内置模块 - path: https://nodejs.org/dist/latest-v12.x/docs/api/path.html
// __dirname：所有情况下，都表示当前运行的js文件所在的目录，它是一个绝对路径。
// path.resolve()  拼接返回绝对路径。

module.exports = {
  mode: 'development',
  output: {
    path: path.resolve(__dirname, 'target'), //必须配置一个绝对路径，表示资源放置的文件夹，默认是dist
    filename: 'bundle.js' //配置的合并的js文件的规则
  },
}

入口 enrty

入口真正配置的是chunk；入口通过entry进行配置。

var path = require('path')

// node内置模块 - path: https://nodejs.org/dist/latest-v12.x/docs/api/path.html
// __dirname：所有情况下，都表示当前运行的js文件所在的目录，它是一个绝对路径。
// path.resolve()  拼接返回绝对路径。
s
module.exports = {
  mode: 'production',
  entry: {
    main: './src/index.js', //属性名：chunk的名称， 属性值：入口模块（启动模块）
    a: ['./src/a.js', './src/index.js'] //启动模块有两个
  },
  output: {
    path: path.resolve(__dirname, 'target'), //必须配置一个绝对路径，表示资源放置的文件夹，默认是dist
    filename: '[id].[chunkhash:5].js' //配置的合并的js文件的规则
  },
  devtool: 'source-map'
}

规则：

多个 chunk 时使用。

name

chunk name

hash

总的资源hash，通常用于解决缓存问题。两个入口对应的总hash 值一致。

chunkhash

使用chunkhash。

两个入口对应的 chunkhash 不一致。

使用chunkid，不推荐。

最佳实践

下面是一些经典场景。

一个页面一个JS

这种方式适用于页面之间的功能差异巨大、公共代码较少的情况，这种情况下打包出来的最终代码不会有太多重复。

源码结构

|—— src
    |—— pageA   页面A的代码目录
        |—— index.js 页面A的启动模块
        |—— ...
    |—— pageB   页面B的代码目录
        |—— index.js 页面B的启动模块
        |—— ...
    |—— pageC   页面C的代码目录
        |—— main1.js 页面C的启动模块1 例如：主功能
        |—— main2.js 页面C的启动模块2 例如：实现访问统计的额外功能
        |—— ...
    |—— common  公共代码目录
        |—— ...

webpack.config.js

module.exports = {
    entry:{
        pageA: "./src/pageA/index.js",
        pageB: "./src/pageB/index.js",
        pageC: ["./src/pageC/main1.js", "./src/pageC/main2.js"]
    },
    output:{
        filename:"[name].[chunkhash:5].js"
    }
}

一个页面多个JS

这种方式适用于页面之间有一些独立、相同的功能，专门使用一个chunk抽离这部分JS有利于浏览器更好的缓存这部分内容。

源码结构

|—— src
    |—— pageA   页面A的代码目录
        |—— index.js 页面A的启动模块
        |—— ...
    |—— pageB   页面B的代码目录
        |—— index.js 页面B的启动模块
        |—— ...
    |—— statistics   用于统计访问人数功能目录
        |—— index.js 启动模块
        |—— ...
    |—— common  公共代码目录
        |—— ...

webpack.config.js

module.exports = {
    entry:{
        pageA: "./src/pageA/index.js",
        pageB: "./src/pageB/index.js",
        statistics: "./src/statistics/index.js"
    },
    output:{
        filename:"[name].[chunkhash:5].js"
    }
}

单页应用

所谓单页应用，是指整个网站（或网站的某一个功能块）只有一个页面，页面中的内容全部靠JS创建和控制。

vue和react都是实现单页应用的利器。

源码结构

|—— src
    |—— subFunc   子功能目录
        |—— ...
    |—— subFunc   子功能目录
        |—— ...
    |—— common  公共代码目录
        |—— ...
    |—— index.js

webpack.config.js

module.exports = {
    entry: "./src/index.js",
    output:{
        filename:"index.[hash:5].js"
    }
}

loader 和 plugin

webpack做的事情，仅仅是分析出各种模块的依赖关系，然后形成资源列表，最终打包生成到指定的文件中。

更多的功能需要借助webpack loaders和 webpack plugins完成。

loader

什么是loader

loader本质上是一个函数，它的作用是将某个源码字符串转换成另一个源码字符串返回。

loader函数的将在模块解析的过程中被调用，以得到最终的源码。

chunk中解析模块的流程

loaders 返回结果交给AST分析。

处理loaders 的流程

有多个loader时，从右向左把loader的结果交给下一个loader。

loader配置

完整配置

module.exports = {
    module: { //针对模块的配置，目前版本只有两个配置，rules、noParse
        rules: [ //模块匹配规则，可以存在多个规则
            { //每个规则是一个对象
                test: /.js$/, //匹配的模块正则
                use: [ //匹配到后应用的规则模块
                    {  //其中一个规则
                        loader: "模块路径", //loader模块的路径，该字符串会被放置到require中
                        options: { //向对应loader传递的额外参数

                        }
                    }
                ]
            }
        ]
    }
}

简化配置

module.exports = {
    module: { //针对模块的配置，目前版本只有两个配置，rules、noParse
        rules: [ //模块匹配规则，可以存在多个规则
            { //每个规则是一个对象
                test: /.js$/, //匹配的模块正则
                use: ["模块路径1", "模块路径2"]//loader模块的路径，该字符串会被放置到require中
            }
        ]
    }
}

自定义loader

src/index.js

变量 a = 1;

loaders/test-loader.js

module.exports = function (sourceCode) {
  // sourceCode：变量 a = 1;
  return 'var a = 1'
}

webpack.config.js

module.exports = {
  mode: 'development',
  module: {
    rules: [
      {
        test: /index\.js$/, //正则表达式，匹配模块的路径
        use: ['./loaders/test-loader'] //匹配到了之后，使用哪些加载器
      }
    ] //模块的匹配规则
  }
}

npx webpack development

可以发现src/index.js 源码中的 变量 a = 1 被替换成了loaders/test-loader.js 的返回值。

完整案例

webpack-note/examples/1.5-loaders/1-自定义loader at master · PantherVkin/webpack-note (github.com)

自定义 style-loader

完整案例

webpack-note/examples/1.5-loaders/2-自定义处理样式 at master · PantherVkin/webpack-note (github.com)

自定义图片处理

完整案例

webpack-note/examples/1.5-loaders/3-自定义图片处理 at master · PantherVkin/webpack-note (github.com)

plugin

loader的功能定位是转换代码，而一些其他的操作难以使用loader完成，比如：

当webpack生成文件时，顺便多生成一个说明描述文件
当webpack编译启动时，控制台输出一句话表示webpack启动了
当xxxx时，xxxx

这种类似的功能需要把功能嵌入到webpack的编译流程中，而这种事情的实现是依托于plugin的。

红点表示触发点，可以被plugin监听。

plugin 的本质

plugin的本质是一个带有apply方法的对象。

var plugin = {
    apply: function(compiler){
        
    }
}

通常，习惯上，我们会将该对象写成构造函数的模式

module.exports = class MyPlugin {
  apply() {
    console.log('插件运行了。')
  }
}

要将插件应用到webpack，需要把插件对象配置到webpack的plugins数组中，如下：

var MyPlugin = require('./plugins/MyPlugins')

module.exports = {
  plugins: [new MyPlugin()]
}

compiler

apply函数会在初始化阶段，创建好Compiler对象后运行。

compiler对象是在初始化阶段构建的，整个webpack打包期间只有一个compiler对象，后续完成打包工作的是compiler对象内部创建的compilation。

apply方法会在创建好compiler对象后调用，并向方法传入一个compiler对象。

compiler对象提供了大量的钩子函数（hooks，可以理解为事件），plugin的开发者可以注册这些钩子函数，参与webpack编译和生成。

你可以在apply方法中使用下面的代码注册钩子函数:

class MyPlugin{
    apply(compiler){
        compiler.hooks.事件名称.事件类型(name, function(compilation){
            //事件处理函数
        })
    }
}

事件名称

即要监听的事件名，即钩子名，所有的钩子：www.webpackjs.com/api/compile…

事件类型

这一部分使用的是 Tapable API，这个小型的库是一个专门用于钩子函数监听的库。

它提供了一些事件类型：

tap：注册一个同步的钩子函数，函数运行完毕则表示事件处理结束
tapAsync：注册一个基于回调的异步的钩子函数，函数通过调用一个回调表示事件处理结束
tapPromise：注册一个基于Promise的异步的钩子函数，函数通过返回的Promise进入已决状态表示事件处理结束

处理函数

处理函数有一个事件参数compilation

案例

module.exports = class MyPlugin {
  apply(compiler) {
    //在这里注册事件，类似于window.onload  $(function(){})
    compiler.hooks.done.tap('MyPlugin-done', function (compilation) {
      //事件处理函数
      console.log('编译完成')
    })
  }
}

完整案例 webpack-note/examples/1.6-plugins/2-使用hook at master · PantherVkin/webpack-note (github.com)

案例：添加文件列表

plugins/FileListPlugin.js

module.exports = class FileListPlugin {
  constructor(filename = 'filelist.txt') {
    this.filename = filename
  }

  apply(compiler) {
    compiler.hooks.emit.tap('FileListPlugin', (complation) => {
      var fileList = []
      for (const key in complation.assets) {
        var content = `【${key}】
大小：${complation.assets[key].size() / 1000}KB`
        fileList.push(content)
      }

      var str = fileList.join('\n\n')
      complation.assets[this.filename] = {
        source() {
          return str
        },
        size() {
          return str.length
        }
      }
    })
  }
}

webpack.config.js

var FileListPlugin = require('./plugins/FileListPlugin')

module.exports = {
  mode: 'development',
  devtool: 'source-map',
  plugins: [new FileListPlugin('文件列表.md')]
}

完整案例

webpack-note/examples/1.6-plugins/3-添加文件列表 at master · PantherVkin/webpack-note (github.com)

区分环境

有些时候，我们需要针对生产环境和开发环境分别书写webpack配置。

webpack 配置函数

为了更好的适应这种要求，webpack允许配置不仅可以是一个对象，还可以是一个函数。

在开始构建时，webpack如果发现配置是一个函数，会调用该函数，将函数返回的对象作为配置内容，因此，开发者可以根据不同的环境返回不同的对象。

module.exports = env => {
    return {
        //配置内容
    }
}

env

在调用webpack函数时，webpack会向函数传入一个参数env，该参数的值来自于webpack命令中给env指定的值。

npx webpack --env abc # env: "abc"

npx webpack --env.abc # env: {abc:true}
npx webpack --env.abc=1  # env： {abc:1}
npx webpack --env.abc=1 --env.bcd=2 # env: {abc:1, bcd:2}

这样一来，我们就可以在命令中指定环境，在代码中进行判断，根据环境返回不同的配置结果。

webpack.config.js 区分环境配置

var baseConfig = require("./webpack.base")
var devConfig = require("./webpack.dev")
var proConfig = require("./webpack.pro")

module.exports = function (env) {
    if (env && env.prod) {
        return {
            ...baseConfig,
            ...proConfig
        }
    }
    else {
        return {
            ...baseConfig,
            ...devConfig
        }
    }
}

其他

context

context: path.resolve(__dirname, "app")

该配置会影响入口和loaders的解析，入口和loaders的相对路径会以context的配置作为基准路径，这样，你的配置会独立于CWD（current working directory 当前执行路径）。

output

library

这样一来，打包后的结果中，会将自执行函数的执行结果暴露给abc。

library: "abc"

libraryTarget

该配置可以更加精细的控制如何暴露入口包的导出结果。

libraryTarget: "var"

其他可用的值有：

var：默认值，暴露给一个普通变量
window：暴露给window对象的一个属性
this：暴露给this的一个属性
global：暴露给global的一个属性
commonjs：暴露给exports的一个属性
其他：www.webpackjs.com/configurati…

target

target:"web" //默认值

设置打包结果最终要运行的环境，常用值有：

web: 打包后的代码运行在web环境中
node：打包后的代码运行在node环境中
其他：www.webpackjs.com/configurati…

module.noParse

noParse: /jquery/

不解析正则表达式匹配的模块，通常用它来忽略那些大型的单模块库，以提高构建性能

resolve

resolve的相关配置主要用于控制模块解析过程。

modules

modules: ["node_modules"]  //默认值

当解析模块时，如果遇到导入语句，require("test")，webpack会从下面的位置寻找依赖的模块。

当前目录下的node_modules目录。

上级目录下的node_modules目录。

...

extensions

extensions: [".js", ".json"]  //默认值

当解析模块时，遇到无具体后缀的导入语句，例如require("test")，会依次测试它的后缀名。

test.js

test.json

alias

alias: {
  "@": path.resolve(__dirname, 'src'),
  "_": __dirname
}

有了alias（别名）后，导入语句中可以加入配置的键名，例如require("@/abc.js")，webpack会将其看作是require(src的绝对路径+"/abc.js")。

在大型系统中，源码结构往往比较深和复杂，别名配置可以让我们更加方便的导入依赖。

externals

从最终的bundle中排除掉配置的源码。

externals: {
    jquery: "$",
    lodash: "_"
}

案例：

例如，入口模块是

//index.js
require("jquery")
require("lodash")

生成的bundle是

(function(){
    ...
})({
    "./src/index.js": function(module, exports, __webpack_require__){
        __webpack_require__("jquery")
        __webpack_require__("lodash")
    },
    "jquery": function(module, exports){
        //jquery的大量源码
    },
    "lodash": function(module, exports){
        //lodash的大量源码
    },
})

但有了上面的配置后，则变成了

(function(){
    ...
})({
    "./src/index.js": function(module, exports, __webpack_require__){
        __webpack_require__("jquery")
        __webpack_require__("lodash")
    },
    "jquery": function(module, exports){
        module.exports = $;
    },
    "lodash": function(module, exports){
        module.exports = _;
    },
})

这比较适用于一些第三方库来自于外部CDN的情况，这样一来，即可以在页面中使用CDN，又让bundle的体积变得更小，还不影响源码的编写。

stats

stats控制的是构建过程中控制台的输出内容。

stats: {
    colors: true,
    modules: false,
    hash: false,
    builtAt: false
}

【工程】webpack 系列 — webpack 核心功能

浏览器端的模块化

浏览器端实现模块化的问题

为什么node端，没有这些问题？

根本原因

解决办法

webpack的安装和使用

webpack简介

安装

使用

打包结果分析【源码】

配置文件

基本配置

devtool 配置

source map

最佳实践

webpack 编译过程

出口和入口

出口 output

入口 enrty

最佳实践

一个页面一个JS

一个页面多个JS

单页应用

loader 和 plugin

loader

什么是loader

loader配置

自定义loader

自定义 style-loader

自定义图片处理

plugin

plugin 的本质

compiler

案例：添加文件列表

区分环境

其他

context

output

module.noParse

resolve

externals

stats