loader 基本上都是第三方类库，使用时需要安装，有一些 loader 还需要安装额外的类库，例如 less-loader 需要 less，babel-loader 需要 babel 等。
loader 匹配规则
loader的配置是放在 module 字段下,如下代码前面提到过：
module.exports = { // ... module: { rules: [ { test: /\.jsx?/,include: [ path.resolve(__dirname,'src'), 指定哪些路径下的文件需要经过 loader 处理 ],use: { loader: 'babel-loader',1)"> 指定使用的 loader options: { presets: ['@babel/preset-env'],}, 一个 object 即一条规则 ],}
loader 的匹配规则中有两个最关键的因素：一个是匹配条件，一个是匹配规则后的应用。
匹配条件通常都使用请求资源文件的绝对路径来进行匹配，在官方文档中称为 resource，除此之外还有比较少用到的 issuer，则是声明依赖请求的源文件的绝对路径。
如下例子：
printer.js Resource: greeter.js,Issuer: printer.js import greetSource from "./greeter"; index.js
issuer：和resource有异曲同工的作用，不过区别在于它是将这个rule应用于哪个文件以及这个文件所导入的所有依赖文件
举个例子：在 /path/to/app.js 中声明引入 import './src/style.scss'，resource 是「/path/to/src/style.scss」，issuer 是「/path/to/app.js」，规则条件会对这两个值来尝试匹配。
上述代码中的 test 和 include 都用于匹配 resource 路径，是 resource.test 和 resource.include 的简写，你也可以这么配置：
module.exports = rules: [ { resource: { resource 的匹配条件 test: /\.jsx?/),],1)"> 如果要使用 issuer 匹配，便是 issuer: { test: ... } },}
issuer 规则匹配的场景比较少见，你可以用它来尝试约束某些类型的文件中只能引用某些类型的文件。
当规则的条件匹配时，便会使用对应的 loader 配置，如上述例子中的 babel-loader
规则条件配置
webpack 的规则提供了多种配置形式：
- { test: ... } 匹配特定条件
- { include: ... } 匹配特定路径
- { exclude: ... } 排除特定路径
- { and: [...] }必须匹配数组中所有条件
- { or: [...] } 匹配数组中任意一个条件
- { not: [...] } 排除匹配数组中所有条件
上述的所谓条件的值可以是：
- 字符串：必须以提供的字符串开始，所以是字符串的话，这里我们需要提供绝对路径
- 正则表达式：调用正则的 test 方法来判断匹配
- 函数：(path) => boolean，返回 true 表示匹配
- 数组：至少包含一个条件的数组
- 对象：匹配所有属性值的条件
例子：
rules: [ { test: /\.jsx?/,1)"> 正则 include: [ path.resolve(__dirname,1)"> 字符串，注意是绝对路径 ],1)"> 数组 },{ resource: { test: { js: /\.js/ 对象，不建议使用 not: [ (value) => { /* ... */ return true; },1)"> 函数，通常需要高度自定义时才会使用 ],} },
test/include/exclude 是resource.(test/include/exclude) 的简写，and/or/not这些则需要放到resource中进行配置。
module type
webpack 4.x 版本强化了 module type，即模块类型的概念，不同的模块类型类似于配置了不同的 loader，webpack 会有针对性地进行处理，现阶段实现了以下 5 种模块类型。
-
javascript/auto：即 webpack 3 默认的类型，支持现有的各种 JS 代码模块类型 —— CommonJS、AMD、ESM -
javascript/esm：ECMAScript modules，其他模块系统，例如 CommonJS 或者 AMD 等不支持，是 .mjs 文件的默认类型 -
javascript/dynamic：CommonJS 和 AMD，排除 ESM -
javascript/json：JSON 格式数据，require 或者 import 都可以引入，是 .json 文件的默认类型 -
webassembly/experimental：WebAssembly modules，当前还处于试验阶段，是 .wasm 文件的默认类型
如果不希望使用默认的类型的话，在确定好匹配规则条件时，我们可以使用 type 字段来指定模块类型，例如把所有的 JS 代码文件都设置为强制使用 ESM 类型：
{ test: /\.js/ 这里指定模块类型 },
上述做法是可以帮助你规范整个项目的模块系统，但是如果遗留太多不同类型的模块代码时，建议还是直接使用默认的javascript/auto。
使用 loader 配置
如下使用use字段：
rules: [ { test: /\.less/ 直接使用字符串表示 loader { loader: 'css-loader' },1)"> 用对象表示 loader，可以传递 loader 配置等 { loader: 'less-loader'true 传递 loader 配置 从上面的配置可以看到，use 字段可以是一个数组，也可以是一个字符串或者表示 loader 的对象。如果只需要一个 loader，也可以这样：use: { loader: 'babel-loader',options: { ... } }。loader 应用顺序
如下配置：
rules: [ { test: /\.js$/"eslint-loader""babel-loader"这样无法法保证 eslint-loader 在 babel-loader 应用前执行。webpack 在rules中提供了一个enforce的字段来配置当前 rule 的 loader 类型，没配置的话是普通类型，我们可以配置pre或post，分别对应前置类型或后置类型的 loader。eslint-loader 要检查的是人工编写的代码，如果在 babel-loader 之后使用，那么检查的是 Babel 转换后的代码，所以必须在 babel-loader 处理之前使用。
还有一种行内 loader，即我们在应用代码中引用依赖时直接声明使用的 loader，如
const json = require('json-loader!./file.json')这种。不建议在应用开发中使用这种 loader所有的 loader 按照前置 -> 行内 -> 普通 -> 后置的顺序执行。所以当我们要确保 eslint-loader 在 babel-loader 之前执行时，可以如下添加 enforce 配置：
rules: [ { enforce: 'pre',1)"> 指定为前置类型 test: /\.js$/使用 noParse
module.noParse字段：可以用于配置哪些模块文件的内容不需要进行解析。对于一些不需要解析依赖（即无依赖）的第三方大型类库等，可以通过这个字段来配置，以提高整体的构建速度。注意：使用 noParse 进行忽略的模块文件中不能使用import、require、define 等导入机制。
如下代码：
module.exports = module: { noParse: /jquery|lodash/,1)"> 正则表达式 或者使用 function noParse(content) { return /jquery|lodash/.test(content) },} }
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。