如何无需安装依赖高效检测npm工作区或其依赖是否变更？

针对npm workspaces单体仓库的测试缓存需求，无需执行npm ci就能覆盖间接依赖变更、内部工作区依赖变更、自身源码变更这三类触发重测的场景，核心思路是直接从根目录的package-lock.json提取精确依赖信息，结合源码哈希生成缓存标识。

核心逻辑 #

package-lock.json已经完整记录了：

• 所有依赖（包括间接）的精确版本与唯一integrity哈希
• 内部工作区依赖的本地路径关联

我们可以通过以下三步生成可靠的缓存key：

步骤1：哈希当前工作区的源码与配置 #

对当前工作区的核心文件做哈希，覆盖自身代码或依赖声明变更的场景：

• 源码目录（如src/）
• 自身的package.json（直接依赖声明变更需触发重测）

示例bash实现：

# 哈希当前工作区的源码与配置文件
WORKSPACE_SRC_HASH=$(find ./src ./package.json -type f | sort | xargs sha256sum | sha256sum | cut -d' ' -f1)

步骤2：提取并哈希当前工作区的所有依赖integrity #

从package-lock.json中提取当前工作区所有依赖（直接+间接）的integrity值并哈希，覆盖间接依赖版本变更的场景：

• 利用jq解析lockfile，定位当前工作区的依赖列表
• 收集每个依赖对应的integrity（lockfile中node_modules/<包名>下的字段）
• 对所有integrity值排序后哈希，确保顺序不影响结果

示例bash实现：

# 获取当前工作区在monorepo中的相对路径（如apps/my-node-app1）
WORKSPACE_REL_PATH=$(pwd | sed 's/.*monorepo\///')

# 提取当前工作区所有依赖的integrity并哈希
DEPENDENCY_INTEGRITY_HASH=$(jq -r --arg ws "$WORKSPACE_REL_PATH" \
  '.packages["packages/$ws"].dependencies | keys[]' \
  ../package-lock.json | while read PKG_NAME; do
    jq -r --arg pkg "$PKG_NAME" \
      '.packages["node_modules/$pkg"].integrity' \
      ../package-lock.json
  done | sort | sha256sum | cut -d' ' -f1)

步骤3：哈希内部工作区依赖的源码 #

对当前工作区依赖的其他内部工作区的源码做哈希，覆盖内部库变更的场景：

• 从lockfile中提取当前工作区依赖的file:开头的本地路径
• 对这些路径下的源码和package.json做哈希

示例bash实现：

# 提取当前工作区依赖的内部工作区路径
INTERNAL_WS_DEPS=$(jq -r --arg ws "$WORKSPACE_REL_PATH" \
  '.packages["packages/$ws"].dependencies | to_entries[] | select(.value | startswith("file:")) | .value[5:]' \
  ../package-lock.json)

# 哈希所有内部工作区的源码与配置
INTERNAL_WS_HASH=$(echo "$INTERNAL_WS_DEPS" | while read DEP_PATH; do
    find "../$DEP_PATH/src" "../$DEP_PATH/package.json" -type f | sort | xargs sha256sum
  done | sha256sum | cut -d' ' -f1)

步骤4：组合最终缓存key #

将以上三个哈希值组合成唯一的缓存key，用于Gitlab CI的缓存标识：

CACHE_KEY="test-cache-${WORKSPACE_REL_PATH//\//-}-$WORKSPACE_SRC_HASH-$DEPENDENCY_INTEGRITY_HASH-$INTERNAL_WS_HASH"
echo "CACHE_KEY=$CACHE_KEY" >> "$CI_ENVIRONMENT_FILE"

注意事项 #

1. 必须保证package-lock.json始终与代码同步提交，否则会导致依赖信息不准确
2. 若工作区使用devDependencies，需在步骤2中同时提取devDependencies的integrity
3. 在Gitlab CI中，可将此脚本作为before_script执行，生成的CACHE_KEY用于定义测试作业的缓存路径

内容的提问来源于stack exchange，提问作者Forivin