包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载本篇指南以 pnpm 仓库GitHub 加速计划 / pn / pnpm中用于端到端测试的夹具包pnpm.e2e/install-script-example为切入点剖析 pnpm 对依赖包生命周期构建脚本install script的执行策略与安全审批机制。读完本文你将掌握--allow-build、ignoredBuilds、approve-builds等核心参数的真实行为并理解该夹具包在 TypeScript 版pnpm11与 Rust 版pnpm/crates测试套件中如何被反复验证。一、夹具包全貌一个用 install 脚本创建文件的测试包pnpm.e2e/install-script-example是 pnpm 项目自带的测试夹具fixture包位于 pnpr/.fixtures/packages/pnpm.e2e/install-script-example/1.0.0/其自身 README 的描述只有一句话A package that creates a file by an install script即一个通过 install 脚本创建文件的包。它的全部内容由三个文件构成麻雀虽小却五脏俱全文件作用README.md包说明文档包含安装命令npm i install-script-example许可证为 MITpackage.json声明包名、版本、install 脚本及许可证create.jsinstall 脚本的实体逻辑负责写入文件1.1 package.jsoninstall 脚本的声明{ name: pnpm.e2e/install-script-example, version: 1.0.0, description: A package that creates a file by an install script, scripts: { test: echo \Error: no test specified\ exit 1, install: node create generated-by-install }, author: Zoltan Kochan zoltan.kochangmail.com (http://kochan.io/), license: MIT, repository: { type: git, url: https://github.com/pnpm/pnpm/tree/master/test/packages/install-script-example } }关键在scripts.install字段node create generated-by-install。这意味着当该包被安装且构建脚本被允许执行时npm/pnpm 会运行node create.js generated-by-install其中generated-by-install作为命令行参数process.argv[2]传入。1.2 create.js脚本如何制造文件use strict const fs require(fs) fs.writeFileSync(process.argv[2] .js, module.exports function () {}\n, utf8)这段代码非常直白以参数名拼接.js后缀写入一个导出一个空函数的模块文件。因此当 install 脚本被允许运行时包目录下会多出一个generated-by-install.js文件——这正是所有相关测试断言的核心产物。整个夹具包的设计意图就是用一个可观察的文件副作用量化验证install 脚本到底有没有被执行。二、为什么需要它pnpm 的构建脚本安全策略单纯看 README 和源码这只是一个极简示例包。它真正的价值体现在测试场景中pnpm 出于供应链安全考虑默认不会执行依赖包的构建脚本preinstall/install/postinstall只有满足特定条件如来自工作区、显式白名单才会执行。而install-script-example恰好提供了一个脚本执行与否可被文件系统直接观测的探针。从仓库源码可以确认这一安全策略的存在。以 TypeScript 版测试 pnpm11/pnpm/test/install/lifecycleScripts.ts 为例execPnpmSync([add, --allow-buildpnpm.e2e/install-script-example, pnpm.e2e/pre-and-postinstall-scripts-example1.0.0, pnpm.e2e/install-script-example]) ... expect(fs.existsSync(node_modules/pnpm.e2e/install-script-example/generated-by-install.js)).toBeTruthy()而在不加任何许可参数时测试则断言generated-by-install.js不存在execPnpmSync([add, --allow-build!pnpm.e2e/install-script-example, pnpm.e2e/install-script-example], { expectSuccess: true }) ... expect(fs.existsSync(node_modules/pnpm.e2e/install-script-example/generated-by-install.js)).toBeFalsy()同样的验证逻辑也完整覆盖在 Rust 版实现中例如 pnpm/crates/cli/tests/suite/lifecycle_scripts/dependency_build_scripts.rs 及其严格模式子测试 strict.rs以及 pnpm/crates/deps-restorer/src/build_modules/ 下的安装与审批测试。这说明两套实现pnpm11 与 pnpm/crates在构建脚本行为上保持了严格的对齐。三、核心机制逐项拆解围绕这个夹具包仓库测试覆盖了以下 pnpm 构建脚本机制的完整行为矩阵。3.1 allow-build白名单放行--allow-buildpkg是命令行级别的临时白名单。上文第一个测试表明传入--allow-buildpnpm.e2e/install-script-example后generated-by-install.js被成功创建。若省略该参数直接pnpm add脚本默认被忽略。注意 pnpm 会区分包名与包名版本两种白名单写法测试中两种形式都出现过见 pnpm11/installing/deps-installer/test/install/lifecycleScripts.ts分别对应全版本放行与单版本放行。3.2 ignoredBuilds被忽略的构建记录当脚本被跳过时pnpm 会把该包记入ignoredBuilds并在后续输出提示。测试中还有一处值得注意的断言expect(result.stdout.toString()).toContain(The following dependencies are ignored by the root project, but are allowed to be built by the current command: pnpm.e2e/install-script-example)即即使根项目配置里忽略了某个依赖的构建当前命令仍可通过--allow-build覆盖放行并给出明确提示。此外测试还验证了选择性重建selective rebuild不会重置 ignoredBuilds 状态——包一旦被忽略除非显式改变策略否则持续处于忽略状态lifecycleScripts.ts。3.3 approve-builds批量审批命令与命令行临时放行对应的是持久化的审批机制pnpm approve-builds。相关测试位于 pnpm11/building/commands/test/policy/approveBuilds.test.tsTypeScript 版与 pnpm/crates/cli/tests/suite/approve_builds.rsRust 版。执行后被批准包的构建白名单会写入项目的pnpm.onlyBuiltDependencies旧版为pnpm.allowBuilds配置中后续安装即可稳定执行该包的构建脚本。测试中断言expect(manifest?.allowBuilds?.[pnpm.e2e/install-script-example]).toBe(true)3.4 严格模式strictRust 版提供了更严格的子测试 strict.rs。在严格模式下任何未经批准的构建脚本不仅被跳过还会以更显式的方式报告便于在 CI 等对确定性要求高的场景中捕获意外构建。3.5 dlx 与全局安装场景夹具包还用于验证pnpm dlx的缓存隔离在 dlx 缓存目录中构建产物应出现在对应版本的 store 路径下例如node_modules/.pnpm/pnpm.e2einstall-script-example1.0.0/node_modules/pnpm.e2e/install-script-example相关断言见 pnpm11/exec/commands/test/dlx.e2e.ts 与 Rust 版 pnpm/crates/cli/tests/suite/dlx.rs。同样全局安装场景pnpm11/pnpm/test/install/global.ts、pnpm/crates/cli/tests/suite/global.rs与 monorepo 场景pnpm11/pnpm/test/monorepo/index.ts也复用该包验证构建脚本行为。四、在本地复现验证你可以不修改仓库、仅通过阅读或临时目录实测来验证上述行为阅读夹具源码查看 create.js 与 package.json确认 install 脚本的副作用。在临时目录中执行pnpm init后运行pnpm add pnpm.e2e/install-script-example观察node_modules/pnpm.e2e/install-script-example/下不会出现generated-by-install.js同时终端会提示该依赖被忽略构建。再执行pnpm add --allow-buildpnpm.e2e/install-script-example pnpm.e2e/install-script-example此时generated-by-install.js出现即脚本确实运行。运行pnpm approve-builds选择批准该包之后再次安装即可持久放行。注意夹具包位于仓库内的 pnpr/.fixtures 目录下并非发布到公开 registry 的常规包本地实测时需要借助仓库的 registry mock 基础设施如 pnpm11/testing/registry-mock或自行将夹具目录作为 file 依赖引入。五、从夹具到机制一叶知秋install-script-example的 README 虽只有数行但它作为测试基础设施的信号发生器反向揭示了 pnpm 在构建脚本治理上的完整链路默认忽略依赖构建脚本 → ignoredBuilds 记录 → allow-build 命令行放行 / approve-builds 持久审批 → 严格模式与 dlx/全局/工作区等场景的一致化处理。当你需要在真实项目中评估某个依赖的安装后脚本安全性时完全可以借鉴这套模式用一个会留下文件副作用的最小包快速验证你的包管理器配置是否按预期拦截或放行构建脚本——这正是该夹具包在 pnpm 测试体系中的核心价值所在。# 快速查看 Rust 版测试中对本夹具的完整断言 # pnpm/crates/cli/tests/suite/lifecycle_scripts/dependency_build_scripts.rs # pnpm/crates/deps-restorer/src/build_modules/tests/installation.rs # pnpm/crates/deps-restorer/src/build_modules/tests/build_policy.rs赞分享包管理器开发工具CLI【免费下载链接】pnpmFast, disk space efficient package manager项目地址https://gitcode.com/gh_mirrors/pn/pnpm点击查看免费下载相关推荐pnpm 重建已安装包构建脚本深入解析 pnpm/building.after-installpnpm 重建已安装包构建脚本深入解析 pnpm/building.after install pnpm/building.after install 是包管理器开发工具CLIProcess Phoenix快速入门5分钟掌握应用重启技巧Process Phoenix快速入门5分钟掌握应用重启技巧 Process Phoenix是一款专注于简化Android应用进程重启的实用工具库能够帮助开移动开发开发工具Flipper Zero 实战指南NarstyBits GoodUSB 脚本集——用 Ducky Script 为 macOS 构建实用工具箱Flipper Zero 实战指南NarstyBits GoodUSB 脚本集——用 Ducky Script 为 macOS 构建实用工具箱 本指南以 Fl示例工程上一篇终极指南SeaTunnel中的JsonPath数据转换插件详解下一篇猫抓Cat-Catch5分钟掌握浏览器视频下载终极指南 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考