本文深入探讨了在已迁移至pnpm的项目中继续使用`npm run`命令的可行性与潜在问题。核心观点是，除了安装阶段，大多数`npm run`命令在pnpm环境中运行良好，但需注意脚本内部调用`pnpm run`的情况以及pnpm对`pre`/`post`钩子脚本的默认处理差异。文章将详细阐述这些注意事项，并提供解决方案，帮助开发者平稳过渡或在混合环境中高效工作，避免不必要的ci/cd修改。
在将项目从npm迁移到pnpm后，许多开发者可能会面临一个问题：是否可以在项目构建、测试等日常操作中继续使用npm run命令，而非立即将所有脚本切换为pnpm run？尤其是在CI/CD流水线中，修改工具链可能涉及大量工作。本文旨在深入解析这种兼容性，并指出潜在的陷阱与解决方案。
兼容性概述
总体而言，在已通过pnpm成功安装依赖的项目中，继续使用npm run来执行package.json中定义的脚本通常是可行的，且不会立即出现明显问题。这是因为npm run和pnpm run的主要职责都是在项目的上下文中查找并执行package.json中定义的脚本命令。在大多数情况下，它们只是一个命令执行器，实际的构建、测试等工具（如Webpack, Jest, TypeScript等）才是真正执行任务的程序，而这些程序在node_modules中，可以通过PATH变量被正确找到。
然而，存在两种关键情况需要特别注意，它们可能导致行为差异或错误。
脚本内部调用pnpm run的场景
如果您的package.json脚本中包含多步骤操作，并且这些步骤明确地调用了pnpm run，那么即使您使用npm run来启动最外层的脚本，也需要确保系统中已安装pnpm。
示例：
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"foo": "echo 'Running foo'",
"bar": "echo 'Running bar'",
"build": "pnpm run foo && pnpm run bar"
}
}在此示例中，如果您执行npm run build，npm会尝试执行字符串pnpm run foo && pnpm run bar。这意味着您的系统环境中必须能够识别并执行pnpm命令。如果pnpm未全局安装或不在系统的PATH中，这个命令将会失败。
注意事项：
- 确保pnpm已全局安装或在项目环境中可访问。
- 这种场景下，npm run仅仅是作为顶层命令的启动器，实际的逻辑流仍由pnpm主导。
pre和post钩子脚本的行为差异
这是npm run与pnpm run之间一个显著且可能导致意外行为的关键区别。
npm的行为： 默认情况下，npm run在执行用户定义的脚本（例如start）时，会自动查找并执行相应的pre和post钩子脚本（例如prestart和poststart）。这种隐式行为可能导致脚本执行流变得不透明，有时会产生意料之外的结果。例如，执行npm run serve可能会意外地触发preserve脚本。
pnpm的行为： pnpm为了提高脚本执行的显式性和可预测性，默认不运行用户自定义脚本的任意pre和post钩子。这意味着，如果您有一个start脚本和一个prestart脚本，当您运行pnpm run start时，prestart脚本默认不会被执行。这种设计旨在避免脚本的隐式执行，使开发者能够更清晰地控制和理解脚本的执行流程。
示例：
{
"name": "my-app",
"version": "1.0.0",
"scripts": {
"prebuild": "echo 'Running prebuild hook'",
"build": "echo 'Building the app'",
"postbuild": "echo 'Running postbuild hook'"
}
}- 使用npm run build：会依次输出 Running prebuild hook -> Building the app -> Running postbuild hook。
- 使用pnpm run build：默认只会输出 Building the app。
如何启用pnpm的pre/post钩子
如果您的项目确实依赖于pre/post钩子脚本的行为，并且希望pnpm也能像npm一样自动执行它们，可以通过配置来启用。
您可以使用以下命令来启用此选项：
pnpm config set enable-pre-post-scripts true
执行此命令后，pnpm会将此设置存储在您的用户配置文件中（通常是~/.config/pnpm/rc）。一旦启用，pnpm run在执行脚本时就会像npm run一样，自动查找并执行相应的pre和post钩子。
总结与最佳实践
在pnpm管理的仓库中继续使用npm run是可行的，但并非没有限制。主要考虑点在于：
- 内部pnpm run调用： 如果您的脚本内部显式调用了pnpm run，请确保pnpm在执行环境中可用。
- pre/post钩子： 了解pnpm默认不执行pre/post钩子的行为，并根据需要通过pnpm config set enable-pre-post-scripts true来启用它们。
最佳实践建议：
- 逐步迁移： 如果CI/CD流水线改造工作量大，可以先在本地开发环境中使用pnpm run，并逐步将CI/CD脚本切换为pnpm run，同时确保所有相关开发者都了解上述差异。
- 明确性优先： pnpm默认不运行pre/post钩子的设计理念是鼓励更显式的脚本定义。如果可能，考虑将pre/post逻辑合并到主脚本中，或通过明确的命令链来调用，而不是依赖隐式钩子。
- 统一工具： 长期来看，为了避免混淆和潜在的兼容性问题，建议最终将项目中的所有脚本执行命令统一为pnpm run。这不仅能确保一致性，还能更好地利用pnpm的特性和性能优势。
通过理解这些兼容性细节和行为差异，开发者可以更自信地在pnpm项目中管理和执行脚本，无论是选择暂时保留npm run，还是全面转向pnpm run。
