pnpm -s lint 被拒绝

项目里有 lint 脚本，执行 pnpm -s lint 却报 unexpected argument '-s' found，改成 pnpm -s run lint 就能运行。pnpm 12 的旧 CLI 在隐式脚本入口上出现过这一参数处理回归；同时还要确认自己要的是静默输出，还是顺序执行，因为 -s 已不能在所有入口都按 silent 理解。

具体反馈包括 pnpm 12.8.1 等旧 12.x 构建，11.28.2 能接受相同命令。处理时记录实际 CLI，不把项目声明的包管理器版本当作已经完成切换：外层启动器可能在交给项目版本之前就拒绝了参数。

显式写 run，说明参数属于哪个命令

pnpm lint 可以使用隐式脚本入口，但在受影响的解析路径中，脚本名并不被当作一个真正的子命令。放在它前面的 -s 没有被移动到 run 的参数位置，留在顶层后被拒绝。

原脚本内容不是这一步的根因。先检查 package.json 中的实际脚本名、命令与错误位置，再使用显式 run 入口。不要为消除解析错误删掉 lint 脚本，或反复清理 node_modules。

若需要按顺序执行任务，使用明确的长参数：

pnpm run --sequential lint

lint 是示例脚本名，应换成项目已有的入口。这条命令会执行脚本，不能当作只读检查。工作区递归调用还应保留原来的选择器、依赖顺序与其他执行选项。

想减少日志时，用 silent 的长写法

当前 pnpm 规则中，run 的 -s 是 --sequential 的缩写；其他 CLI 入口中的 -s 仍可表示 --reporter=silent。长参数 --silent 不受这种短名区别影响。

如果原意是静默运行某个脚本，可以写清楚：

pnpm --silent run lint

这只表达 pnpm 的静默输出策略，不会要求脚本内部所有工具都停止输出。脚本自己打印的结果、告警或错误仍应按它的接口处理，不能为了静默把退出状态和失败日志一起丢掉。

从旧 11.x 流程迁移时尤其要比较两件事：命令是否能执行，-s 的实际含义是否仍符合预期。有的版本已经接受短参数，却把它用于顺序执行；解析成功并不证明原来的日志行为被保留。

更新 CLI 后仍要复查原入口

采用包含相应解析修复、与项目兼容的正式版本，可以恢复隐式脚本入口的短参数处理。升级前保留包管理器约束与锁文件差异，并核对实际启动器、CI 缓存和项目内再次调用的 pnpm。

仍需要更换命令写法时，把显式 run 与所需长参数一起保存在团队脚本中，避免本地用一套、CI 又用另一套。不要单独给 packageManager 改一个版本号后，假定外层 CLI 也已经更新。

最后用原脚本检查执行结果、退出状态，以及确实需要的任务顺序和输出行为。撤回时一起恢复审定的启动方式和参数，不让“静默”和“顺序”两种意图继续共用一个含义不清的短选项。