一、从一个真实的“惊吓”说起
想象一下这个场景：你的团队正在为一个重要的项目进行最后的冲刺，大家信心满满。突然，安全部门发来一封紧急邮件，指出你们项目里引入的一个第三方库，其开源许可证与公司政策严重冲突，或者更糟，这个库本身被曝出存在严重的安全漏洞。整个团队瞬间从“冲刺模式”切换到“救火模式”，需要紧急排查、评估、替换这个依赖，项目进度一下子被打乱。
这种“惊吓”在软件开发中并不少见。随着项目像滚雪球一样越滚越大，依赖的第三方包也越来越多，手动去检查每一个包的许可证或安全状态，几乎是一项不可能完成的任务。我们急需一种自动化的“守门员”，在不良依赖试图混进项目的那一刻，就果断地将其拒之门外。今天，我们就来聊聊如何利用 Yarn 的一个强大功能——Constraints（约束），来打造这样一位智能的“项目守门员”。
简单来说，Yarn Constraints 允许你编写一些自定义的“规则手册”。Yarn 在安装或更新依赖时，会对照这本手册进行检查，一旦发现有依赖违反了规则，就会立即报错并停止操作。这就像给项目的依赖管理加装了一套自动安检系统。
二、认识我们的工具：Yarn Constraints 初探
在深入编写规则之前，我们先快速了解一下 Yarn Constraints 是什么。它是 Yarn（一个流行的 JavaScript 包管理器）内置的一个特性，其核心思想是“将策略作为代码”。你可以编写一个约束规则文件（通常是 .yarnrc.yml 中配置或独立的文件），用清晰的代码逻辑来定义依赖关系必须满足的条件。
启用 Constraints 非常简单。首先，确保你使用的是 Yarn 2（Berry）或更高版本。然后，在你的项目根目录下的 .yarnrc.yml 文件中进行配置，并创建一个约束定义文件。
技术栈：Node.js / JavaScript 项目，包管理器为 Yarn Berry
# 项目根目录下的 .yarnrc.yml 配置文件
# 启用 constraints 功能，并指定我们的约束规则文件路径
constraintsPath: ./.yarn/constraints.pro
接下来，我们就在 .yarn/constraints.pro 文件里大展身手了。这个文件使用一种名为 Prolog 的声明式逻辑编程语言的子集来编写规则，听起来有点唬人，但别担心，用于依赖约束的语法非常直观，我们通过例子就能很快掌握。
三、动手编写我们的第一条“禁令”
理论说得再多，不如动手写一行代码。让我们从一个最直接的需求开始：禁止项目引入某个已知的有风险或许可证不兼容的包。
假设我们通过某些渠道得知，一个名为 dangerous-legacy-lib 的包存在严重安全漏洞，而另一个叫 restrictive-license-pkg 的包使用的是 GPL 许可证，与我们的 MIT 许可项目不兼容。我们需要禁止它们被加入项目。
# 文件：.yarn/constraints.pro
# 技术栈：Yarn Constraints (Prolog语法子集)
# 规则一：禁止安装特定的危险包
gen_enforced_field(WorkspaceCwd, ‘dependencies‘, ‘dangerous-legacy-lib‘, null).
gen_enforced_field(WorkspaceCwd, ‘devDependencies‘, ‘dangerous-legacy-lib‘, null).
gen_enforced_field(WorkspaceCwd, ‘peerDependencies‘, ‘dangerous-legacy-lib‘, null).
# 规则二：禁止安装特定许可证的包
gen_enforced_field(WorkspaceCwd, ‘dependencies‘, ‘restrictive-license-pkg‘, null).
gen_enforced_field(WorkspaceCwd, ‘devDependencies‘, ‘restrictive-license-pkg‘, null).
gen_enforced_field(WorkspaceCwd, ‘peerDependencies‘, ‘restrictive-license-pkg‘, null).
# 注释说明：
# 1. `gen_enforced_field` 是一个内置的约束谓词，用于强制某个字段的值。
# 2. `WorkspaceCwd` 代表当前工作区（项目）的路径。
# 3. 第二个参数是依赖类型：`dependencies`（生产依赖）、`devDependencies`（开发依赖）、`peerDependencies`（同伴依赖）。
# 4. 第三个参数是我们想要禁止的包名。
# 5. 第四个参数 `null` 是关键！它表示“强制该字段的值为空”，即不允许这个包存在。
现在，当任何开发者试图运行 yarn add dangerous-legacy-lib 时，Yarn 会立刻报错，提示违反了约束规则，安装过程被中止。这就在源头上杜绝了特定包被引入的可能。
但是，一个一个地列出黑名单包太累了，而且我们可能更关心包的属性，比如它的许可证（license）字段。让我们来写一个更智能的规则。
四、进阶：基于许可证类型的自动化过滤
我们的目标升级了：我们希望自动禁止所有使用 GPL、AGPL 等传染性许可证的包被加入。这需要我们能够读取到包的“许可证”信息。
Yarn Constraints 提供了 dependency 谓词，可以让我们获取到依赖树的详细信息。结合 Yarn 的元数据获取能力，我们可以写出更强大的规则。
# 文件：.yarn/constraints.pro
# 技术栈：Yarn Constraints (Prolog语法子集)
# 定义一个辅助规则：判断一个许可证字符串是否为我们需要禁止的
has_prohibited_license(License) :-
# 将许可证字符串转换为小写，方便匹配
LicenseLower is lowercase(License),
(
# 使用正则表达式匹配各种 GPL 变体（这里简化处理，实际正则可能更复杂）
sub_string(LicenseLower, _, ‘gpl‘, _);
sub_string(LicenseLower, _, ‘agpl‘, _);
# 可以继续添加其他禁止的许可证关键词，如 ‘cc-by-nc-sa‘ 等
sub_string(LicenseLower, _, ‘cc-by-nc‘, _)
).
# 主规则：遍历所有依赖，如果其许可证被禁止，则强制移除它
gen_enforced_field(WorkspaceCwd, DependencyType, DependencyName, null) :-
# 获取项目中的某个依赖
dependency(WorkspaceCwd, DependencyType, DependencyName),
# 尝试获取这个依赖的许可证信息（来自 package.json 的 `license` 字段）
get_dependency_field(WorkspaceCwd, DependencyType, DependencyName, ‘license‘, License),
# 调用上面定义的规则，判断该许可证是否被禁止
has_prohibited_license(License).
# 注释说明：
# 1. `dependency(WorkspaceCwd, Type, Name)`：遍历匹配工作区中所有指定类型的依赖。
# 2. `get_dependency_field(...)`：获取指定依赖的某个字段值，这里我们获取 `license` 字段。
# 3. `has_prohibited_license` 是我们自定义的逻辑判断规则。
# 4. 整个规则的意思是：对于每一个依赖，如果它的许可证字段值匹配了被禁止的许可证类型，那么就强制执行 `gen_enforced_field`，将其值设为 `null`（即禁止）。
这个规则就强大且自动化多了！它不再针对具体的包名，而是针对包的属性（许可证）进行过滤。无论开发者想安装什么新包，只要它的许可证是 GPL 系列的，Yarn 都会自动拦截。
五、场景扩展：结合外部数据源进行风险检查
有时候，风险信息并不在 package.json 的静态字段里。比如，我们想禁止引入已知存在高危安全漏洞（CVE） 的包版本。这时，我们需要结合外部数据源。
一个常见的做法是，在约束规则执行前，先通过一个脚本（如 Node.js 脚本）去查询像 npm audit 或第三方安全数据库（如 Snyk、OSS Index 的 API），生成一个当前已知的风险包列表，并将其写入一个 Yarn Constraints 能读取的格式（比如另一个 .pro 文件或 JSON 文件）。然后在主约束文件中引入这个“黑名单”。
假设我们有一个脚本生成了 risk_list.pro 文件：
# 文件：.yarn/risk_list.pro (由外部安全扫描脚本自动生成)
# 内容格式：记录有风险的包名和其最高安全版本
risk_package(‘lodash‘, ‘4.17.20‘). # lodash 在 4.17.20 之前有原型污染漏洞
risk_package(‘express‘, ‘4.17.2‘). # express 在某个版本前有漏洞
然后，在我们的主约束文件中引入并应用这个风险列表：
# 文件：.yarn/constraints.pro
# 技术栈：Yarn Constraints (Prolog语法子集)
# 引入外部生成的风险列表文件
include(‘./.yarn/risk_list.pro‘).
# 规则：禁止安装风险包的危险版本
gen_enforced_field(WorkspaceCwd, DependencyType, DependencyName, null) :-
# 获取项目中的某个依赖及其当前声明的版本范围
dependency(WorkspaceCwd, DependencyType, DependencyName, DependencyRange),
# 检查这个包是否在风险列表中
risk_package(DependencyName, SafeVersion),
# 关键判断：如果当前声明的版本范围不满足“高于安全版本”，则禁止。
# 这里 `doesnt_satisfy` 是一个简化的逻辑表示，实际需要更复杂的版本语义判断。
# Yarn Constraints 提供了 `semver_satisfies` 等谓词来处理版本，但逻辑会稍复杂。
# 为了示例清晰，我们简化表示为：如果依赖的版本 <= SafeVersion，则触发规则。
# 注意：实际实现需要根据 `DependencyRange` 和 `SafeVersion` 进行精确的语义化版本判断，可能需调用外部函数。
not(semver_satisfies(SafeVersion, DependencyRange)).
# 注释：此示例的最后版本比较部分为概念演示，实际编写需要更严谨地处理版本范围语义。
通过这种方式，我们将自动化的安全扫描与依赖安装流程无缝集成，实现了真正的“安全左移”，在安装阶段就规避了已知风险。
六、技术优缺点与注意事项
优点：
- 自动化与预防性：将人工审查转化为自动检查，在问题发生前预防，极大提升效率和代码安全质量。
- 策略即代码：规则文件可以被版本控制（如 Git）管理，方便团队协作、评审和追溯变更历史。
- 灵活强大：基于 Prolog 的规则引擎，可以表达非常复杂的依赖关系逻辑，不局限于许可证和漏洞。
- 无缝集成：作为 Yarn 原生功能，无需额外复杂的 CI/CD 流水线步骤，在
yarn install时自动执行。
缺点与挑战：
- 学习曲线：Prolog 语法对于大多数前端和 JavaScript 开发者来说比较陌生，需要时间学习和理解。
- 规则复杂性：编写精确的规则，尤其是处理复杂的版本范围语义时，可能有难度，容易写出有误的规则。
- 性能考量：非常复杂的约束规则或在巨型项目上运行，可能会稍微增加依赖解析的时间。
- 仅限 Yarn：这个方案只适用于使用 Yarn Berry 的项目，对于使用 npm 或 pnpm 的项目不直接适用。
重要注意事项：
- 规则测试：在将严格的约束规则应用到主分支或生产项目前，务必在特性分支或本地进行充分测试，避免误杀合法依赖，阻碍正常开发。
- 误报处理：需要建立机制处理“误报”。比如某个 GPL 包确实是项目必需，且法律上已获得豁免，这时可能需要有机制（如注释排除、白名单规则）来临时或永久绕过某条约束。
- 版本范围处理：如示例所示，处理“禁止某个版本以下”的规则时，必须精确理解语义化版本（SemVer）和版本范围（如
^1.2.3,~4.5.0,>=2.0.0 <3.0.0）的含义，确保规则逻辑正确。 - 与 CI/CD 结合：虽然 Constraints 在本地就能工作，但在 CI/CD 流水线中强制执行约束检查（例如，在
yarn install后运行yarn constraints）是确保团队规范一致性的最佳实践。
七、总结
在软件供应链安全日益受到重视的今天，被动响应漏洞和许可证问题已经远远不够。Yarn Constraints 为我们提供了一种主动、内嵌、自动化的防御手段。通过编写自定义规则，我们可以轻松实现：
- 法律合规自动化：自动拦截与项目许可证策略冲突的依赖。
- 安全漏洞前置拦截：结合安全数据源，在安装阶段阻止已知有风险版本的引入。
- 依赖架构治理：甚至可以定义更复杂的规则，比如强制某些包使用相同版本、禁止循环依赖等。
虽然需要克服一定的学习曲线，但将“依赖策略”转化为清晰、可维护、可执行的代码，其带来的长期收益——更安全的项目、更合规的代码库、更高效的团队协作——无疑是巨大的。不妨从今天开始，为你最重要的项目配置第一条约束规则，迈出构建健壮软件供应链的第一步。
评论