不同模块化标准

不同的模块化标准，webpack按照如下的方式处理

编译结果分析

//合并两个模块
//  ./src/a.js
//  ./src/index.js

(function (modules) {
    var moduleExports = {}; //用于缓存模块的导出结果

    //require函数相当于是运行一个模块，得到模块导出结果
    function __webpack_require(moduleId) { //moduleId就是模块的路径
        if (moduleExports[moduleId]) {
            //检查是否有缓存
            return moduleExports[moduleId];
        }

        var func = modules[moduleId]; //得到该模块对应的函数
        var module = {
            exports: {}
        }
        func(module, module.exports, __webpack_require); //运行模块
        var result = module.exports; //得到模块导出的结果
        moduleExports[moduleId] = result; //缓存起来
        return result;
    }

    //执行入口模块
    return __webpack_require("./src/index.js"); //require函数相当于是运行一个模块，得到模块导出结果
})({ //该对象保存了所有的模块，以及模块对应的代码
    "./src/a.js": function (module, exports) {
        eval("console.log(\"module a\")\nmodule.exports = \"a\";\n //# sourceURL=webpack:///./src/a.js")
    },
    "./src/index.js": function (module, exports, __webpack_require) {
        eval("console.log(\"index module\")\nvar a = __webpack_require(\"./src/a.js\")\na.abc();\nconsole.log(a)\n //# sourceURL=webpack:///./src/index.js")
      
    }
});

配置文件

webpack提供的cli支持很多的参数，例如--mode，但更多的时候，我们会使用更加灵活的配置文件来控制webpack的行为

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

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

注意：配置文件中的代码，必须是有效的node代码

当命令行参数与配置文件中的配置出现冲突时，以命令行参数为准。

基本配置：

1. mode：编译模式，字符串，取值为development或production，指定编译结果代码运行的环境，会影响webpack对编译结果代码格式的处理
2. entry：入口，字符串（后续会详细讲解），指定入口文件
3. output：出口，对象（后续会详细讲解），指定编译结果文件

devtool配置

module.exports = {
    mode: "production",
    devtool: "hidden-source-map"
}

source map 源码地图

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

最佳实践：

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

webpack中的source map

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

具体的配置见文档：www.webpackjs.com/configurati…

编译过程

webpack 的作用是将源代码编译（构建、打包）成最终代码

整个过程大致分为三个步骤

1. 初始化
2. 编译
3. 输出

初始化

此阶段，webpack会将CLI参数、配置文件、默认配置进行融合，形成一个最终的配置对象。

对配置的处理过程是依托一个第三方库yargs完成的

此阶段相对比较简单，主要是为接下来的编译阶段做必要的准备

目前，可以简单的理解为，初始化阶段主要用于产生一个最终的配置

编译

1. 创建chunk

chunk是webpack在内部构建过程中的一个概念，译为块，它表示通过某个入口找到的所有依赖的统称。

chunk可以有多个

根据入口模块（默认为./src/index.js）创建一个chunk。

每个chunk都有至少两个属性：

• name：默认为main
• id：唯一编号，开发环境和name相同，生产环境是一个数字，从0开始

2. 构建所有依赖模块

• 入口模块文件：./src/index.js

• 检查模块是否加载

• 读取文件内容： require('./a'); require('./b');

• AST抽象语法树分析：树形结构遍历，找到依赖

• 记录依赖：['./src/a.js','./src/b.js']

• 替换依赖函数，转换后的代码：__webpack_require('./src/a.js'); __webpack_require('./src/b.js');

• 保存替换后的代码：

  • 模块id: ./src/index.js
  • 转换后的代码: __webpack_require('./src/a.js'); __webpack_require('./src/b.js');

• 入口模块文件：./src/a.js

• 检查模块是否加载

• 读取文件内容：require('./b');

• AST抽象语法树分析：树形结构遍历，找到依赖

• 记录依赖：['./src/b.js']

• 替换依赖函数，转换后的代码：---

• 保存替换后的代码：

  • 模块id: ./src/a.js

  • 转换后的代码:---

根据依赖进行递归，直到找完所有模块。

3. 产生chunk assets

在第二步完成后，chunk中会产生一个模块列表，列表中包含了模块id和模块转换后的代码

接下来，webpack会根据配置为chunk生成一个资源列表，即chunk assets，资源列表可以理解为是生成到最终文件的文件名和文件内容

4. 合并chunk assets

将多个chunk的assets合并到一起，并产生一个总的hash

输出

此步骤非常简单，webpack将利用node中的fs模块（文件处理模块），根据编译产生的总的assets，生成相应的文件。

1. module：模块，分割的代码单元，webpack中的模块可以是任何内容的文件，不仅限于JS
2. chunk：webpack内部构建模块的块，一个chunk中包含多个模块，这些模块是从入口模块通过依赖分析得来的
3. bundle：chunk构建好模块后会生成chunk的资源清单，清单中的每一项就是一个bundle，可以认为bundle就是最终生成的文件
4. hash：最终的资源清单所有内容联合生成的hash值
5. chunkhash：chunk生成的资源清单内容联合生成的hash值
6. chunkname：chunk的名称，如果没有配置则使用main
7. id：通常指chunk的唯一编号，如果在开发环境下构建，和chunkname相同；如果是生产环境下构建，则使用一个从0开始的数字进行编号

入口和出口

入口

入口真正配置的是chunk

入口通过entry进行配置

规则：

• name：chunkname
• hash: 总的资源hash，通常用于解决缓存问题
• chunkhash: 使用chunkhash
• id: 使用chunkid，不推荐

出口

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

出口通过output进行配置

filename: "[id].[chunkhash:5].js" //配置的合并的js文件的规则 可以解决浏览器缓存问题

配置文件

var path = require("path")

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"
}

入口和出口的最佳实践

一个页面一个JS

• 源码结构

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

• webpack配置

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

• 源码结构

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

• webpack配置

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

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

单页应用

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

• 源码结构

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

• webpack配置

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

loader

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

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

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

loader运行的时机

loader实现

module.exports = function(sourceCode) {
    console.log('prev',sourceCode);
    const res = sourceCode.replace(/变量/g, 'const a');
    console.log('cur',res);
    return res;
}

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实操

loader处理样式

• loder配置

module.exports = {
    mode: 'development',
    devtool: 'source-map',
    module: {
        rules: [{
            test: /\.css$/, //将这里的css文件内容进行转化
            use: ['./loader/cssLoader.js']
        }]
    }
}

• cssLoader.js

module.exports = function(sourceCode){
    const code = `
        var style = document.createElement('style');
        style.innerHTML = \`${sourceCode}\`;
        document.head.appendChild(style);
        module.exports = \`${sourceCode}\`;
    `;
    return code;
}

• index.js

const style = require('./assets/index.css');

console.log(style);

loader处理图片

• loader配置

module.exports = {
    mode: 'development',
    devtool: 'source-map',
    module: {
        rules: [{
            test: /\.css$/,
            use: ['./loader/cssLoader.js']
        },{
            test: /\.(png)|(jpg)|(jpeg)$/,
            use: [{
                loader: './loader/imageLoader.js',
                options: {
                    limit: 3000, //3000字节以上使用图片，3000字节以内使用base64
                    filename: "img-[contenthash:5].[ext]"
                }
            }]
        }]
    }
}

• imageLoader.js

var loaderUtil = require("loader-utils")

function loader(buffer) { //给的是buffer
    console.log("文件数据大小：(字节)", buffer.byteLength);
    var { limit = 1000, filename = "[contenthash].[ext]" } = loaderUtil.getOptions(this);
    if (buffer.byteLength >= limit) {
        var content = getFilePath.call(this, buffer, filename);
    }
    else{
        var content = getBase64(buffer)
    }
    return `module.exports = \`${content}\``;
}

loader.raw = true; //该loader要处理的是原始数据

module.exports = loader;

function getBase64(buffer) {
    return "data:image/png;base64," + buffer.toString("base64");
}

function getFilePath(buffer, name) {
    var filename = loaderUtil.interpolateName(this, name, {
        content: buffer
    });
    this.emitFile(filename, buffer);
    return filename;
}

const image = require('./assets/1.png');

console.log(image);
const img = document.createElement("img")
img.src = image;
document.body.appendChild(img);

plugin

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

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

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

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

class MyPlugin{
    apply(compiler){

    }
}

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

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

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

compiler对象是在初始化阶段构建的，整个webpack打包期间只有一个compiler对象，后续完成打包工作的是compiler对象内部创建的compilation(有文件改动就会重新运行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

区分环境

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

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

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

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

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

• webpack4

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}

• webpack5

npx webpack --env abc # env:{abc:true}

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}

module.exports = (env) => {
    if(env && env.prod){ // 生产环境
        return {
            mode: "production"
        }
    }
    if(env && env.dev){ // 开发环境
        return {
            mode: 'development',
            devtool: 'source-map'
        }
    }
}

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

其它细节配置

context

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

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

const path = require('path');
module.exports = {
    mode: 'development',
    entry: {
        main: './a.js', // 若设置了context,那么这里的相对路径就相对context值的路径
    },
    context: path.resolve(__dirname, 'src'),
}

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会从下面的位置寻找依赖的模块

1. 当前目录下的node_modules目录
2. 上级目录下的node_modules目录
3. ...

题

const a = require('a.js');

寻找依赖a是webpack去找，还是node去找？ webpack

if(Math.random() < 0.5){
    require('./a')
}

打包结果中，包含：

• index和a（正确答案）
• index
• index，有可能有a

extensions

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

当解析模块时，遇到无具体后缀的导入语句，例如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控制的是构建过程中控制台的输出内容

常用扩展

1. 清除输出目录 clean-webpack-plugin
2. 自动生成页面 html-webpack-plugin
3. 复制静态资源 copy-webpack-plugin
4. 开发服务器 webpack-dev-server
5. 普通文件处理

开发依赖

npm i -D xxxx --registry https://registry.npm.taobao.org

const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const HtmlWebpackPlugin  = require('html-webpack-plugin');
const CopyWebpackPlugin = require('copy-webpack-plugin');
const path = require('path');

module.exports = {
    mode: 'development',
    devtool: 'source-map',
    output: {
        filename: '[name].[chunkhash].js',
        path: path.resolve(__dirname, 'dist')
    },
    plugins: [
        new CleanWebpackPlugin(),
        // 页面生成模版
        new HtmlWebpackPlugin({
            template: './public/index.html'
        }),
        new CopyWebpackPlugin({
            patterns: [
                { from: "./public/images", to: "./images" },
            ],
        })
    ],
    devServer: {
            port: 12306,
            open: true, // 自动打开浏览器
            proxy: { // 代理
                '/api':{
                    target: 'http://open.duyiedu.com',
                    changeOrigin: true //更改请求头中的host和origin
                }
            }
        }
}

普通文件处理

有的时候我们是同js导入文件资源，然后加入到页面上去的，这个时候希望导入的模块结果是一个可用的资源路径。

file-loader: 生成依赖的文件到输出目录，然后将模块文件设置为：导出一个路径

//file-loader
function loader(source){
	// source：文件内容（图片内容 buffer）
	// 1. 生成一个具有相同文件内容的文件到输出目录
	// 2. 返回一段代码   export default "文件名"
}

url-loader：将依赖的文件转换为：导出一个base64格式的字符串

//file-loader
function loader(source){
	// source：文件内容（图片内容 buffer）
	// 1. 根据buffer生成一个base64编码
	// 2. 返回一段代码   export default "base64编码"
}

• 配置

module: {
    rules: [
        {
            test: /\.(png)|(gif)|(jpg)$/,
            use: [{
                loader: "url-loader",
                options: {
                    // limit: false //不限制任何大小，所有经过loader的文件进行base64编码返回
                    limit: 10 * 1024, //只要文件不超过 100*1024 字节，则使用base64编码，否则，交给file-loader进行处理
                    name: "imgs/[name].[hash:5].[ext]"
                }
            }]
        }
    ]
},

解决路径问题

在使用file-loader或url-loader时，可能会遇到一个非常有趣的问题

比如，通过webpack打包的目录结构如下：

dist
    |—— img
        |—— a.png  #file-loader生成的文件
    |—— scripts
        |—— main.js  #export default "img/a.png"
    |—— html
        |—— index.html #<script src="../scripts/main.js" ></script>

这种问题发生的根本原因：模块中的路径来自于某个loader或plugin，当产生路径时，loader或plugin只有相对于dist目录的路径，并不知道该路径将在哪个资源中使用，从而无法确定最终正确的路径

面对这种情况，需要依靠webpack的配置publicPath解决

webpack内置插件

所有的webpack内置插件都作为webpack的静态属性存在的，使用下面的方式即可创建一个插件对象

const webpack = require("webpack")

new webpack.插件名(options)

DefinePlugin

全局常量定义插件，使用该插件通常定义一些常量值，例如：

new webpack.DefinePlugin({
    PI: `Math.PI`, // PI = Math.PI
    VERSION: `"1.0.0"`, // VERSION = "1.0.0"
    DOMAIN: JSON.stringify("duyi.com")
})

这样一来，在源码中，我们可以直接使用插件中提供的常量，当webpack编译完成后，会自动替换为常量的值

BannerPlugin

它可以为每个chunk生成的文件头部添加一行注释，一般用于添加作者、公司、版权等信息

new webpack.BannerPlugin({
  banner: `
  hash:[hash]
  chunkhash:[chunkhash]
  name:[name]
  author:yuanjin
  corporation:duyi
  `
})

ProvidePlugin

自动加载模块，而不必到处 import 或 require

new webpack.ProvidePlugin({
  $: 'jquery',
  _: 'lodash'
})

然后在我们任意源码中：

$('#item'); // <= 起作用
_.drop([1, 2, 3], 2); // <= 起作用

css工程化

利用webpack拆分css

要拆分css，就必须把css当成像js那样的模块；要把css当成模块，就必须有一个构建工具（webpack），它具备合并代码的能力

而webpack本身只能读取css文件的内容、将其当作JS代码进行分析，因此，会导致错误

于是，就必须有一个loader，能够将css代码转换为js代码

css-loader

css-loader的作用，就是将css代码转换为js代码

它的处理原理极其简单：将css代码作为字符串导出

例如：

.red{
    color:"#f40";
}

经过css-loader转换后变成js代码：

module.exports = `.red{
    color:"#f40";
}`

上面的js代码是经过我简化后的，不代表真实的css-loader的转换后代码，css-loader转换后的代码会有些复杂，同时会导出更多的信息，但核心思想不变

再例如：

.red{
    color:"#f40";
    background:url("./bg.png")
}

经过css-loader转换后变成js代码：

var import1 = require("./bg.png");
module.exports = `.red{
    color:"#f40";
    background:url("${import1}")
}`;

这样一来，经过webpack的后续处理，会把依赖./bg.png添加到模块列表，然后再将代码转换为

var import1 = __webpack_require__("./src/bg.png");
module.exports = `.red{
    color:"#f40";
    background:url("${import1}")
}`;

再例如：

@import "./reset.css";
.red{
    color:"#f40";
    background:url("./bg.png")
}

会转换为：

var import1 = require("./reset.css");
var import2 = require("./bg.png");
module.exports = `${import1}
.red{
    color:"#f40";
    background:url("${import2}")
}`;

总结，css-loader干了什么：

1. 将css文件的内容作为字符串导出
2. 将css中的其他依赖作为require导入，以便webpack分析依赖

style-loader

由于css-loader仅提供了将css转换为字符串导出的能力，剩余的事情要交给其他loader或plugin来处理

style-loader可以将css-loader转换后的代码进一步处理，将css-loader导出的字符串加入到页面的style元素中

例如：

.red{
    color:"#f40";
}

经过css-loader转换后变成js代码：

module.exports = `.red{
    color:"#f40";
}`

经过style-loader转换后变成：

module.exports = `.red{
    color:"#f40";
}`
var style = module.exports;
var styleElem = document.createElement("style");
styleElem.innerHTML = style;
document.head.appendChild(styleElem);
module.exports = {}

以上代码均为简化后的代码，并不代表真实的代码 style-loader有能力避免同一个样式的重复导入

BEM

BEM是一套针对css类样式的命名方法。

其他命名方法还有：OOCSS、AMCSS、SMACSS等等

BEM全称是：Block Element Modifier

一个完整的BEM类名：block__element_modifier，例如：banner__dot_selected，可以表示：轮播图中，处于选中状态的小圆点

三个部分的具体含义为：

• Block：页面中的大区域，表示最顶级的划分，例如：轮播图(banner)、布局(layout)、文章(article)等等
• element：区域中的组成部分，例如：轮播图中的横幅图片(banner__img)、轮播图中的容器（banner__container）、布局中的头部(layout__header)、文章中的标题(article_title)
• modifier：可选。通常表示状态，例如：处于展开状态的布局左边栏（layout__left_expand）、处于选中状态的轮播图小圆点(banner__dot_selected)

在某些大型工程中，如果使用BEM命名法，还可能会增加一个前缀，来表示类名的用途，常见的前缀有：

• l: layout，表示这个样式是用于布局的
• c: component，表示这个样式是一个组件，即一个功能区域
• u: util，表示这个样式是一个通用的、工具性质的样式
• j: javascript，表示这个样式没有实际意义，是专门提供给js获取元素使用的

css in js

css in js 的核心思想是：用一个JS对象来描述样式，而不是css样式表

例如下面的对象就是一个用于描述样式的对象：

const styles = {
    backgroundColor: "#f40",
    color: "#fff",
    width: "400px",
    height: "500px",
    margin: "0 auto"
}

由于这种描述样式的方式根本就不存在类名，自然不会有类名冲突

至于如何把样式应用到界面上，不是它所关心的事情，你可以用任何技术、任何框架、任何方式将它应用到界面。

后续学习的vue、react都支持css in js，可以非常轻松的应用到界面

css in js的特点：

• 绝无冲突的可能：由于它根本不存在类名，所以绝不可能出现类名冲突
• 更加灵活：可以充分利用JS语言灵活的特点，用各种招式来处理样式
• 应用面更广：只要支持js语言，就可以支持css in js，因此，在一些用JS语言开发移动端应用的时候非常好用，因为移动端应用很有可能并不支持css
• 书写不便：书写样式，特别是公共样式的时候，处理起来不是很方便
• 在页面中增加了大量冗余内容：在页面中处理css in js时，往往是将样式加入到元素的style属性中，会大量增加元素的内联样式，并且可能会有大量重复，不易阅读最终的页面代码

/**
* 给某个dom元素应用一个样式
* @param {*} dom dom元素
* @param {*} styles 样式对象
*/
export function applyStyles(dom, ...styles) {
    let targetStyles = {}; //最终合并的样式对象
    for (const style of styles) {
        targetStyles = {
            ...targetStyles,
            ...style
        }
    }

    for (const key in targetStyles) {
        const value = targetStyles[key];
        dom.style[key] = value;
    }
}

css module

通过命名规范来限制类名太过死板，而css in js虽然足够灵活，但是书写不便。 css module 开辟一种全新的思路来解决类名冲突的问题

思路

css module 遵循以下思路解决类名冲突问题：

1. css的类名冲突往往发生在大型项目中
2. 大型项目往往会使用构建工具（webpack等）搭建工程
3. 构建工具允许将css样式切分为更加精细的模块
4. 同JS的变量一样，每个css模块文件中难以出现冲突的类名，冲突的类名往往发生在不同的css模块文件中
5. 只需要保证构建工具在合并样式代码后不会出现类名冲突即可

实现原理

在webpack中，作为处理css的css-loader，它实现了css module的思想，要启用css module，需要将css-loader的配置modules设置为true。

css-loader的实现方式如下：

原理极其简单，开启了css module后，css-loader会将样式中的类名进行转换，转换为一个唯一的hash值。

由于hash值是根据模块路径和类名生成的，因此，不同的css模块，哪怕具有相同的类名，转换后的hash值也不一样。

如何应用样式

css module带来了一个新的问题：源代码的类名和最终生成的类名是不一样的，而开发者只知道自己写的源代码中的类名，并不知道最终的类名是什么，那如何应用类名到元素上呢？

为了解决这个问题，css-loader会导出原类名和最终类名的对应关系，该关系是通过一个对象描述的

这样一来，我们就可以在js代码中获取到css模块导出的结果，从而应用类名了

style-loader为了我们更加方便的应用类名，会去除掉其他信息，仅暴露对应关系

其他操作

全局类名

某些类名是全局的、静态的，不需要进行转换，仅需要在类名位置使用一个特殊的语法即可：

:global(.main){
    ...
}

使用了global的类名不会进行转换，相反的，没有使用global的类名，表示默认使用了local

:local(.main){
    ...
}

使用了local的类名表示局部类名，是可能会造成冲突的类名，会被css module进行转换

如何控制最终的类名

绝大部分情况下，我们都不需要控制最终的类名，因为控制它没有任何意义

如果一定要控制最终的类名，需要配置css-loader的localIdentName

其他注意事项

• css module往往配合构建工具使用
• css module仅处理顶级类名，尽量不要书写嵌套的类名，也没有这个必要
• css module仅处理类名，不处理其他选择器
• css module还会处理id选择器，不过任何时候都没有使用id选择器的理由
• 使用了css module后，只要能做到让类名望文知意即可，不需要遵守其他任何的命名规范

CSS预编译器

基本原理

编写css时，受限于css语言本身，常常难以处理一些问题：

• 重复的样式值：例如常用颜色、常用尺寸
• 重复的代码段：例如绝对定位居中、清除浮动
• 重复的嵌套书写

由于官方迟迟不对css语言本身做出改进，一些第三方机构开始想办法来解决这些问题

其中一种方案，便是预编译器

预编译器的原理很简单，即使用一种更加优雅的方式来书写样式代码，通过一个编译器，将其转换为可被浏览器识别的传统css代码

目前，最流行的预编译器有LESS和SASS，由于它们两者特别相似，因此仅学习一种即可（本课程学习LESS）

less官网：lesscss.org/ less中文文档1（非官方）：lesscss.cn/ less中文文档2（非官方）：less.bootcss.com/ sass官网：sass-lang.com/ sass中文文档1（非官方）：www.sass.hk/ sass中文文档2（非官方）：sass.bootcss.com/

LESS的安装和使用

从原理可知，要使用LESS，必须要安装LESS编译器

LESS编译器是基于node开发的，可以通过npm下载安装

npm i -D less

安装好了less之后，它提供了一个CLI工具lessc，通过该工具即可完成编译

lessc less代码文件 编译后的文件

试一试:

新建一个index.less文件，编写内容如下：

// less代码
@red: #f40;

.redcolor {
    color: @red;
}

运行命令：

lessc index.less index.css

可以看到编译之后的代码：

.redcolor {
  color: #f40;
}

LESS的基本使用

具体的使用见文档：less.bootcss.com/

• 变量
• 混合
• 嵌套
• 运算
• 函数
• 作用域
• 注释
• 导入

在webpack中使用less

• less-loader

module.exports = {
    mode: "development",
    devServer: {
        open: true
    },
    module: {
        rules: [
            { test: /\.css$/, use: ["style-loader", "css-loader"] },
            { test: /\.less$/, use: ["style-loader", "css-loader?modules", "less-loader"] },
        ]
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: "./public/index.html"
        })
    ]
}

PostCss

什么是PostCss

学习到现在，可以看出，CSS工程化面临着诸多问题，而解决这些问题的方案多种多样。

如果把CSS单独拎出来看，光是样式本身，就有很多事情要处理。

既然有这么多事情要处理，何不把这些事情集中到一起统一处理呢？

PostCss就是基于这样的理念出现的。

PostCss类似于一个编译器，可以将样式源码编译成最终的CSS代码

看上去是不是和LESS、SASS一样呢？

但PostCss和LESS、SASS的思路不同，它其实只做一些代码分析之类的事情，将分析的结果交给插件，具体的代码转换操作是插件去完成的。

官方的一张图更能说明postcss的处理流程：

这一点有点像webpack，webpack本身仅做依赖分析、抽象语法树分析，其他的操作是靠插件和加载器完成的。

官网地址：postcss.org/ github地址：github.com/postcss/pos…

安装

PostCss是基于node编写的，因此可以使用npm安装

npm i -D postcss

postcss库提供了对应的js api用于转换代码，如果你想使用postcss的一些高级功能，或者想开发postcss插件，就要api使用postcss，api的文档地址是：api.postcss.org/

不过绝大部分时候，我们都是使用者，并不希望使用代码的方式来使用PostCss

因此，我们可以再安装一个postcss-cli，通过命令行来完成编译

npm i -D postcss-cli

postcss-cli提供一个命令，它调用postcss中的api来完成编译

命令的使用方式为：

postcss 源码文件 -o 输出文件

配置文件

和webpack类似，postcss有自己的配置文件，该配置文件会影响postcss的某些编译行为。

配置文件的默认名称是：postcss.config.js

例如：

module.exports = {
    map: false, //关闭source-map
}

插件

光使用postcss是没有多少意义的，要让它真正的发挥作用，需要插件

postcss的插件市场：www.postcss.parts/

下面罗列一些postcss的常用插件

postcss-preset-env

过去使用postcss的时候，往往会使用大量的插件，它们各自解决一些问题

这样导致的结果是安装插件、配置插件都特别的繁琐

于是出现了这么一个插件postcss-preset-env，它称之为postcss预设环境，大意就是它整合了很多的常用插件到一起，并帮你完成了基本的配置，你只需要安装它一个插件，就相当于安装了很多插件了。

安装好该插件后，在postcss配置中加入下面的配置

module.exports = {
    plugins: {
        "postcss-preset-env": {} // {} 中可以填写插件的配置
    }
}

该插件的功能很多，下面一一介绍

自动的厂商前缀

某些新的css样式需要在旧版本浏览器中使用厂商前缀方可实现

例如

::placeholder {
    color: red;
}

该功能在不同的旧版本浏览器中需要书写为

::-webkit-input-placeholder {
    color: red;
}
::-moz-placeholder {
    color: red;
}
:-ms-input-placeholder {
    color: red;
}
::-ms-input-placeholder {
    color: red;
}
::placeholder {
    color: red;
}

要完成这件事情，需要使用autoprefixer库。

而postcss-preset-env内部包含了该库，自动有了该功能。

如果需要调整兼容的浏览器范围，可以通过下面的方式进行配置

方式1：在postcss-preset-env的配置中加入browsers

module.exports = {
    plugins: {
        "postcss-preset-env": {
            browsers: [
                "last 2 version",
                "> 1%"
            ]
        } 
    }
}

方式2【推荐】：添加 .browserslistrc 文件

创建文件.browserslistrc，填写配置内容

last 2 version
> 1%

方式3【推荐】：在package.json的配置中加入browserslist

"browserslist": [
    "last 2 version",
    "> 1%"
]

browserslist是一个多行的（数组形式的）标准字符串。

它的书写规范多而繁琐，详情见：github.com/browserslis…

一般情况下，大部分网站都使用下面的格式进行书写

last 2 version
> 1% in CN
not ie <= 8

• last 2 version: 浏览器的兼容最近期的两个版本
• > 1% in CN: 匹配中国大于1%的人使用的浏览器， in CN可省略
• not ie <= 8: 排除掉版本号小于等于8的IE浏览器

默认情况下，匹配的结果求的是并集

你可以通过网站：browserl.ist/ 对配置结果覆盖的浏览器进行查询，查询时，多行之间使用英文逗号分割

browserlist的数据来自于CanIUse网站，由于数据并非实时的，所以不会特别准确

未来的CSS语法

CSS的某些前沿语法正在制定过程中，没有形成真正的标准，如果希望使用这部分语法，为了浏览器兼容性，需要进行编译

过去，完成该语法编译的是cssnext库，不过有了postcss-preset-env后，它自动包含了该功能。

你可以通过postcss-preset-env的stage配置，告知postcss-preset-env需要对哪个阶段的css语法进行兼容处理，它的默认值为2

"postcss-preset-env": {
    stage: 0
}

一共有5个阶段可配置：

• Stage 0: Aspirational - 只是一个早期草案，极其不稳定
• Stage 1: Experimental - 仍然极其不稳定，但是提议已被W3C公认
• Stage 2: Allowable - 虽然还是不稳定，但已经可以使用了
• Stage 3: Embraced - 比较稳定，可能将来会发生一些小的变化，它即将成为最终的标准
• Stage 4: Standardized - 所有主流浏览器都应该支持的W3C标准

了解了以上知识后，接下来了解一下未来的css语法，尽管某些语法仍处于非常早期的阶段，但是有该插件存在，编译后仍然可以被浏览器识别

变量

未来的css语法是天然支持变量的

在:root{}中定义常用变量，使用--前缀命名变量

:root{
    --lightColor: #ddd;
    --darkColor: #333;
}

a{
    color: var(--lightColor);
    background: var(--darkColor);
}

编译后，仍然可以看到原语法，因为某些新语法的存在并不会影响浏览器的渲染，尽管浏览器可能不认识 如果不希望在结果中看到新语法，可以配置postcss-preset-env的preserve为false

自定义选择器

@custom-selector :--heading h1, h2, h3, h4, h5, h6;
@custom-selector :--enter :focus,:hover;

a:--enter{
    color: #f40;
}

:--heading{
    font-weight:bold;
}

:--heading.active{
    font-weight:bold;
}

编译后

a:focus,a:hover{
    color: #f40;
}

h1,h2,h3,h4,h5,h6{
    font-weight:bold;
}

h1.active,h2.active,h3.active,h4.active,h5.active,h6.active{
    font-weight:bold;
}

嵌套

与LESS相同，只不过嵌套的选择器前必须使用符号&

.a {
    color: red;
    & .b {
        color: green;
    }

    & > .b {
        color: blue;
    }

    &:hover {
        color: #000;
    }
}

编译后

.a {
    color: red
}

.a .b {
    color: green;
}

.a>.b {
    color: blue;
}

.a:hover {
    color: #000;
}

postcss-apply

该插件可以支持在css中书写属性集

类似于LESS中的混入，可以利用CSS的新语法定义一个CSS代码片段，然后在需要的时候应用它

:root {
  --center: {
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translate(-50%, -50%);
  };
}

.item{
    @apply --center;
}

编译后

.item{
  position: absolute;
  left: 50%;
  top: 50%;
  -webkit-transform: translate(-50%, -50%);
  transform: translate(-50%, -50%);
}

实际上，该功能也属于cssnext，不知为何postcss-preset-env没有支持

postcss-color-function

该插件支持在源码中使用一些颜色函数

body {
    /* 使用颜色#aabbcc，不做任何处理，等同于直接书写 #aabbcc */
    color: color(#aabbcc);
    /* 将颜色#aabbcc透明度设置为90% */
    color: color(#aabbcc a(90%));
    /* 将颜色#aabbcc的红色部分设置为90% */
    color: color(#aabbcc red(90%));
    /* 将颜色#aabbcc调亮50%（更加趋近于白色），类似于less中的lighten函数 */
    color: color(#aabbcc tint(50%));
    /* 将颜色#aabbcc调暗50%（更加趋近于黑色），类似于less中的darken函数 */
    color: color(#aabbcc shade(50%));
}

编译后

body {
    /* 使用颜色#aabbcc，不做任何处理，等同于直接书写 #aabbcc */
    color: rgb(170, 187, 204);
    /* 将颜色#aabbcc透明度设置为90% */
    color: rgba(170, 187, 204, 0.9);
    /* 将颜色#aabbcc的红色部分设置为90% */
    color: rgb(230, 187, 204);
    /* 将颜色#aabbcc调亮50%（更加趋近于白色），类似于less中的lighten函数 */
    color: rgb(213, 221, 230);
    /* 将颜色#aabbcc调暗50%（更加趋近于黑色），类似于less中的darken函数 */
    color: rgb(85, 94, 102);
}

[扩展]postcss-import

该插件可以让你在postcss文件中导入其他样式代码，通过该插件可以将它们合并

由于后续的课程中，会将postcss加入到webpack中，而webpack本身具有依赖分析的功能，所以该插件的实际意义不大

stylelint

官网：stylelint.io/

在实际的开发中，我们可能会错误的或不规范的书写一些css代码，stylelint插件会即时的发现错误

由于不同的公司可能使用不同的CSS书写规范，stylelint为了保持灵活，它本身并没有提供具体的规则验证

你需要安装或自行编写规则验证方案

通常，我们会安装stylelint-config-standard库来提供标准的CSS规则判定

安装好后，我们需要告诉stylelint使用该库来进行规则验证

告知的方式有多种，比较常见的是使用文件.stylelintrc

//.styleintrc
{
  "extends": "stylelint-config-standard"
}

此时，如果你的代码出现不规范的地方，编译时将会报出错误

body {
    background: #f4;
}

发生了两处错误：

1. 缩进应该只有两个空格
2. 十六进制的颜色值不正确

如果某些规则并非你所期望的，可以在配置中进行设置

{
    "extends": "stylelint-config-standard",
    "rules": {
        "indentation": null
    }
}

设置为null可以禁用该规则，或者设置为4，表示一个缩进有4个空格。具体的设置需要参见stylelint文档：stylelint.io/

但是这种错误报告需要在编译时才会发生，如果我希望在编写代码时就自动在编辑器里报错呢？

既然想在编辑器里达到该功能，那么就要在编辑器里做文章

安装vscode的插件stylelint即可，它会读取你工程中的配置文件，按照配置进行实时报错

实际上，如果你拥有了stylelint插件，可以不需要在postcss中使用该插件了

在webpack中使用postCss

• postcss-loader

抽离css文件

目前，css代码被css-loader转换后，交给的是style-loader进行处理。

style-loader使用的方式是用一段js代码，将样式加入到style元素中。

而实际的开发中，我们往往希望依赖的样式最终形成一个css文件

此时，就需要用到一个库：mini-css-extract-plugin

该库提供了1个plugin和1个loader

• plugin：负责生成css文件
• loader：负责记录要生成的css文件的内容，同时导出开启css-module后的样式对象

使用方式：

const MiniCssExtractPlugin = require("mini-css-extract-plugin")
module.exports = {
    module: {
        rules: [
            {
                test: /\.css$/, use: [MiniCssExtractPlugin.loader, "css-loader?modules"]
            }
        ]
    },
    plugins: [
        new MiniCssExtractPlugin() //负责生成css文件
    ]
}

配置生成的文件名

同output.filename的含义一样，即根据chunk生成的样式文件名

配置生成的文件名，例如[name].[contenthash:5].css

默认情况下，每个chunk对应一个css文件