在从npm迁移到pnpm后，通常可以继续使用npm run命令执行项目脚本。主要需要关注两点：一是package.json脚本内部是否显式调用了pnpm run，这要求pnpm必须可用；二是pnpm默认不执行pre和post钩子脚本，这与npm的行为不同，若有需求可手动配置启用。理解这些差异有助于平稳过渡并优化ci/cd流程。
当项目从npm（或其他包管理器）迁移到pnpm后，开发者常常面临一个实际问题：是否可以继续使用npm run命令来执行package.json中定义的脚本，尤其是在CI/CD流程中，为了避免大量修改而希望暂时保留现有命令。本文将深入探讨在pnpm管理的项目中执行npm run命令的兼容性、潜在问题及解决方案。
npm run 与 pnpm run 的基本机制
无论是npm run
从这个角度看，只要pnpm成功安装了所有依赖，并且相应的二进制文件存在于node_modules/.bin中，那么理论上npm run和pnpm run执行相同的脚本时，其结果应该是相同的。因为它们最终都是调用相同的底层可执行文件。
显式 pnpm run 调用带来的影响
然而，存在一种特殊情况需要注意：如果package.json中的某个脚本内部显式地调用了pnpm run来执行子任务，那么使用npm run执行该脚本时，可能会遇到问题。
考虑以下package.json脚本示例：
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"clean": "rimraf dist",
"compile": "tsc",
"build": "pnpm run clean && pnpm run compile"
},
"dependencies": {
"rimraf": "^3.0.2",
"typescript": "^4.0.0"
}
}在这个例子中，build脚本内部明确地使用了pnpm run clean和pnpm run compile。如果你尝试运行npm run build，操作系统会尝试执行pnpm run clean。如果你的环境中没有全局安装pnpm，或者pnpm不在系统的PATH中，那么这个命令将会失败，提示找不到pnpm命令。
解决方案：
- 确保pnpm可用： 如果你的脚本确实需要内部调用pnpm run，那么在执行npm run命令的环境中，必须确保pnpm是可用的（例如，通过全局安装pnpm或将其添加到PATH中）。
-
重构脚本： 更好的做法是，如果这些子任务是项目内部的，可以直接调用它们，例如：
{ "scripts": { "build": "npm run clean && npm run compile" // 或者直接调用二进制文件，如果它们在node_modules/.bin中 // "build": "rimraf dist && tsc" } }当然，在pnpm项目中，最佳实践是统一使用pnpm run来执行所有脚本。
关键差异：pre 和 post 钩子脚本的行为
npm run和pnpm run之间最显著的功能差异体现在它们处理pre和post钩子脚本的方式上。
npm的行为： npm在执行用户定义的脚本（例如start、build、test）时，会默认自动查找并执行对应的pre
和post 钩子脚本。例如，运行npm run build会自动触发prebuild和postbuild脚本。这种隐式执行机制有时会导致脚本行为不透明，难以追踪。 pnpm的行为： pnpm默认不执行这些隐式的pre和post钩子脚本。这是pnpm为了提高脚本执行的明确性和可预测性而做出的设计选择。例如，执行pnpm run build将只会运行build脚本本身，而不会自动触发prebuild或postbuild。
示例：
假设package.json中有如下脚本：
{
"scripts": {
"prebuild": "echo 'Running prebuild tasks (by npm)'",
"build": "echo 'Running main build task'",
"postbuild": "echo 'Running postbuild tasks (by npm)'"
}
}-
使用 npm run build 的输出：
Running prebuild tasks (by npm) Running main build task Running postbuild tasks (by npm)
-
使用 pnpm run build 的默认输出：
Running main build task
你会发现prebuild和postbuild脚本没有被执行。
如何恢复 pre/post 钩子行为：
如果你的项目确实依赖于pre/post钩子脚本（例如，某些旧项目或特定的构建流程），pnpm提供了配置选项来恢复这一行为。你可以通过以下命令启用它：
pnpm config set enable-pre-post-scripts true
这个设置会存储在用户主目录下的pnpm配置文件中（通常是~/.config/pnpm/rc）。启用后，pnpm run的行为将与npm run在pre/post钩子方面保持一致。
注意事项： 启用此选项会使pnpm的行为更接近npm，但同时也可能引入pnpm设计者试图避免的隐式执行问题。建议仅在确实需要时启用，并优先考虑将pre/post逻辑显式地整合到主脚本中。
CI/CD管道中的考虑
对于CI/CD管道，如果项目刚刚从npm迁移到pnpm，而修改所有npm run命令的工作量较大，那么暂时保留npm run命令是可行的，但需要注意以下几点：
- 全面测试： 在迁移后，务必在CI环境中运行完整的测试套件和构建流程，以确保所有脚本的行为都符合预期。特别要留意那些依赖pre/post钩子的脚本。
- pnpm可用性： 如果任何脚本内部显式调用了pnpm run，CI环境中必须确保pnpm命令是可用的。
- 长期规划： 尽管暂时兼容，但最终目标应该是将CI/CD管道中的所有包管理相关命令统一为pnpm，以确保开发和生产环境的一致性，并充分利用pnpm的性能和磁盘空间优化优势。
总结
在pnpm管理的项目中，使用npm run命令执行脚本通常是兼容的，因为它们最终都调用node_modules/.bin中的二进制文件。然而，有两点关键差异需要特别关注：
- 脚本内部的显式 pnpm run 调用： 如果脚本内部调用了pnpm run，那么执行环境必须能够找到pnpm命令。
- pre 和 post 钩子脚本的行为： pnpm默认不执行这些隐式钩子。如果项目依赖这些钩子，需要通过pnpm config set enable-pre-post-scripts true手动启用。
理解并妥善处理这些差异，可以帮助开发者在迁移过程中实现平稳过渡，并为后续全面拥抱pnpm的最佳实践打下基础。
