pnpm filter 没有生效

.pnpmfile.mjs 的 updateConfig 已经返回了 filter，执行 pnpm install 却仍安装整个工作区。升级到 pnpm 12 后出现这一变化时，应检查钩子的选择条件是否在配置处理时被丢弃，尤其是用 Git sparse checkout 只保留部分项目的仓库。

这个具体回归在 pnpm 12.8.2 中出现，正式 12.11.2 已包含修复：钩子返回的 filter、filterProd 可以参与递归命令的项目选择。命令行显式传入的 --filter 或 --filter-prod 仍优先，这一点不是故障。

确认是钩子的选择条件被丢掉

先确认实际 pnpm 版本、当前工作区根目录与钩子文件位置，并核对这次命令确实会加载 updateConfig。如果钩子没有被读取，或逻辑根本没有返回预期选择条件，就不能套用这里的版本结论。

受影响的配置路径把钩子结果作为 pnpm-workspace.yaml 设置处理，filter 并不属于那组设置，于是被略过。安装继续执行，表面上没有钩子错误，却用了默认的工作区选择范围。其他有效配置项能生效，也不能证明 filter 已保留。

下面是放在工作区根目录 .pnpmfile.mjs 中的局部示例；需要合入已有钩子，而不是覆盖整份文件：

export const hooks = {
  updateConfig(config) {
    if (config.filter == null && config.filterProd == null) {
      config.filter = ["@example/app"];
    }
    return config;
  },
};

@example/app 是占位包名，应换成工作区实际存在的项目。示例仅在调用方没有给出选择条件时设置默认值，保留命令行覆盖能力；真实 sparse checkout 项目还应沿用原来识别磁盘上项目的逻辑，不能把固定包名当成通用自动发现方案。

修复版本后，保留两种调用行为

项目已采用 pnpm 12 时，按既有包管理器安装方式与锁定策略选择包含修复的正式版本，例如 12.11.2。确认本地、CI 和实际启动器都使用新版本，再执行原本不带显式 filter 的安装。

不能立即更新时，可以在受控环境中给原命令明确指定相同选择范围：

pnpm install --filter @example/app

这会执行安装并可能改变依赖目录及锁文件。先保存原配置和锁文件，使用项目真实的选择器，不为了验证把稀疏工作区所有未在磁盘上的成员都补装或清理。已有脚本要同时保留其他安装选项。

修复后的钩子也不应该夺走调用方的显式选择。分别检查不带参数时采用钩子默认范围、带 --filter 时采用命令行范围。若发现两者不同，先判断是不是原来的优先级规则，不能一律把覆盖当成回归。

安装范围正确，才算恢复

核对实际参与安装的项目、依赖目录和锁文件差异。命令退出为零，并不能证明只操作了期望的成员；sparse checkout 中未落盘项目的依赖信息也不应因排错而被意外改写。

如果新版本仍安装整个工作区，继续检查实际加载的钩子、返回值、选择器是否匹配，以及命令行或包装脚本是否覆盖配置。不要反复删掉锁文件，或用全局环境设置强压所有项目：这些做法会扩大影响，却没有说明选择条件在哪一步失效。