loader

webpack做的事情，仅仅是分析出各种模块的依赖关系，然后形成资源列表，最终打包生成到指定的文件中。更多的功能需要借助webpack loaders和webpack plugins完成。

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

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

全流程：

chunk中解析模块的流程：

chunk中解析模块的更详细流程：

处理loaders流程：

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中
            }
        ]
    }
}

plugin

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

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

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

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

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

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

class MyPlugin{
    apply(compiler){

    }
}

var plugin = new MyPlugin();

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

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

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

区分环境 {ignore}

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

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

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

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

在调用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}

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

其他细节配置 {ignore}

context

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

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

output

library

library: "abc"

这样一来，打包后的结果中，会将自执行函数的执行结果暴露给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

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

从最终的bundle中排除掉配置的配置的源码，例如，入口模块是

//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控制的是构建过程中控制台的输出内容

Webpack笔记三