Webpack 5 发布后，模块联邦、持久化缓存等特性被反复讨论，但有一个隐藏在配置层面的变化很少被单独拿出来讲：它让构建配置从随意堆砌的文本，变成了一部具有约束力的“宪法”。社区里有人把这套机制称为 Constitutionalism，也就是“宪政”。这个说法虽然不是官方 API 名称，却非常贴切地概括了 Webpack 5 在配置校验、规则继承和依赖边界三个方向上的升级。本文不纠缠命名争议，而是聚焦这些能力如何解决实际构建痛点。
一、旧配置模式为什么需要一场“宪政”改革
在 Webpack 4 及更早版本中，配置文件更像是一份备忘录，而不是一份具备强制力的规则文档。开发者可以在 module.rules 里随意添加多条规则，只要最后构建不报错，就没人在意某段 CSS 被重复处理了几次。比如下面这个配置，两条规则都匹配了 .css 文件，css-loader 被执行两遍，构建时间白白增加，而问题只有在性能分析时才会暴露。
// 一个容易被忽略的重复处理示例
module.exports = {
module: {
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] },
{ test: /\.css$/, use: ['css-loader'] }
]
}
};
这种“人治”模式还体现在依赖引用上。开发者可以随心所欲地 import 一个模块的深层文件，例如 import Button from '../../components/button/src/index.js'，这完全绕过了组件库的公开入口，一旦内部结构变动，构建就会在毫无征兆的情况下失败。Webpack 4 虽然提供了 resolve.alias、extensions 等选项，但它们更像交通标志，是否遵守依然依赖开发者自觉。
更深层的问题是配置错误往往在编译后期才暴露。Webpack 4 对配置对象的校验并不严格，比如把 module.rules 写成 module.rule，构建器会静默忽略，直到产物内容不符合预期，开发者才开始反向排查。这三类痛点——规则冲突、边界缺失、错误延迟——共同构成了旧配置体系的顽疾，也为 Webpack 5 的宪政化改造提供了动机。
二、Webpack 5 的“宪法条款”：三类硬约束机制
Webpack 5 并没有直接提供一个叫 Constitutionalism 的插件，但它通过底层机制让配置文件具备更强的“法律效力”。第一类约束来自配置 schema 校验。Webpack 5 引入了更完整的 JSON Schema 定义，对配置对象的每个字段进行类型和形状检查。如果你把 entry 写成字符串数组，或者把 module.rules 的某个规则对象漏掉 test 属性，启动阶段就会直接抛出带路径的错误信息，而不是等到产物阶段才失败。
第二类约束是 module.rules 的条件语法与 oneOf 的强制互斥。旧版本中，多个规则可以同时命中同一个文件，Webpack 会按照数组顺序全部执行，这经常造成重复处理。Webpack 5 强化了 oneOf 语义，使用它之后，同一个文件只会进入第一个匹配的规则，后续规则自动跳过。结合 include、exclude 以及全新的 issuer、dependency 条件，开发者可以精确划定每类资源的处理权限。
第三类约束是模块导入边界的收口。Webpack 5 完整支持 package.json 中的 exports 字段，并且允许通过 resolve.exportsFields 调整解析优先级。一个包一旦在 package.json 里声明了 exports，外部导入者就只能访问这些入口，任何试图 import 包内部路径的行为都会在解析阶段被拒绝。这相当于给每个模块颁发了“宪法条文”，明确了什么可以对外，什么必须保持私有。
下面这段配置展示了这三类约束的协同工作方式。它利用 oneOf 避免 CSS 规则冲突，同时通过 resolve 的约束阻止绕过公开入口的深层引用。
const path = require('path');
module.exports = {
entry: './src/main.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist')
},
module: {
rules: [
{
oneOf: [
{
test: /\.css$/,
include: path.resolve(__dirname, 'src/styles'),
use: ['style-loader', 'css-loader']
},
{
test: /\.(png|jpe?g|gif)$/,
type: 'asset/resource'
}
]
}
]
},
resolve: {
exportsFields: ['exports'],
byDependency: {
esm: {
exportsFields: ['exports', 'module']
}
}
}
};
上述代码中，oneOf 保证 CSS 文件只被第一条规则处理，即使后面还有能匹配 .css 的规则也不会执行。资源文件通过 type: 'asset/resource' 直接交给 Webpack 5 的资产模块处理，不再需要 file-loader 等外部依赖。resolve.exportsFields 则指示解析器优先读取 package.json 的 exports 字段，从而强制模块通过公开入口导入。
三、实战落地：从一份“宪法文件”开始治理构建
要把这套宪政思路落到真实项目中，不建议一上来就把所有规则写死。更务实的做法是先拆分配置结构，把基础规则、开发规则和生产规则分开管理。例如使用 webpack-merge 工具组合多个配置文件，基础文件只保留所有环境共用的规则，开发文件通过 merge 追加 devServer 和 sourcemap，生产文件则追加压缩和缓存配置。这样每一份配置的职责边界清晰，修改时不会误伤其他环境。
在基础配置中，优先使用 oneOf 组织 loader 规则，并为每类资源指定明确的 include 或 exclude 目录。这样做有两个好处：一是减少不必要的文件系统遍历，二是防止某类规则意外处理不属于它的文件。对于依赖边界，检查项目内部是否引用了 node_modules 包的私有路径，如果存在，逐步改用包的公开入口，并在 package.json 中为组件库添加 exports 声明。
进一步，可以利用 TypeScript 定义配置类型。Webpack 5 提供了完整的类型声明，当使用 defineConfig 辅助函数时，编辑器会在你写下错误字段名或类型不匹配的值时立即给出提示。这对于多人协作的团队尤其有效，因为配置错误在提交代码之前就已经被拦截。
// webpack.config.ts
import { defineConfig } from 'webpack';
export default defineConfig({
module: {
rules: [
{
oneOf: [
{ test: /\.ts$/, use: 'ts-loader', exclude: /node_modules/ }
]
}
]
},
resolve: {
extensions: ['.ts', '.js'],
exportsFields: ['exports']
}
});
这段 TypeScript 配置在编译阶段就能发现字段拼写错误，并把规则约束控制在编译范围内。团队还可以把这份配置纳入 CI 流程，每次提交都执行一次 Webpack 配置校验，确保“宪法”不被破坏。
四、宪政的边界：哪些项目适合引入这种约束
需要明确的是，宪政模式并不是所有项目的灵丹妙药。对于只有十几个文件的小型演示项目，严格的规则约束可能带来额外的学习成本和维护负担。开发者需要先理解 oneOf 与普通规则数组的区别，还要维护 package.json 的 exports 字段，这些工作在早期会显得繁琐。如果把约束做得过于复杂，反而会让新成员对构建配置望而生畏。
真正能从中获益的是大型单体仓库、微前端应用、组件库和跨团队协作项目。这类场景中，模块数量庞大，依赖关系复杂，任何一次越界引用都可能引发连锁故障。通过 exports 字段禁止深层导入，可以强制所有消费方使用公开接口，降低内部重构的破坏性。借助配置类型检查，可以提前发现大部分低级错误，减少构建失败后的排查时间。
落地的关键还是渐进式推进。先从最痛的点开始，比如修复重复规则冲突，再逐步引入依赖边界约束。同时配合代码评审，让团队成员理解每一条“宪法条款”存在的意义，而不是把约束当成额外的负担。当构建日志里不再出现重复处理的警告，当深层导入在解析阶段就被拒绝时，你会意识到这套宪政机制正在悄悄提升整个工程的可维护性。