[Bug]: unsafe defaults for cache.buildDependencies

[escaton]

Version

System:
    OS: macOS 15.7.2
    CPU: (14) arm64 Apple M4 Pro
    Memory: 1.16 GB / 24.00 GB
    Shell: 5.9 - /bin/zsh
  Browsers:
    Chrome: 144.0.7559.97
    Firefox: 147.0.1
    Safari: 26.1
  npmPackages:
    @rsbuild/core: 1.7.2 => 1.7.2 
    @rsbuild/plugin-type-check: 1.3.3 => 1.3.3 
    @rsbuild/plugin-vue: 1.2.3 => 1.2.3

Details

https://rsbuild.rs/config/performance/build-cache#default-value
Currently the cache depends on package.json among other files, but not on any of the lock files such as package-lock.json, pnpm-lock.yaml, yarn.lock etc. This makes it possible to mistakenly reuse cache while actual content of node_modules could be different.

Proposal: add known popular lock files to the buildDependencies: npm, pnpm, yarn, bun.

Reproduce link

Reproduce Steps

[chenjiahan]

Lockfiles can change the resolved dependency graph, so I agree there's a potential correctness risk in some workflows.

I'm hesitant to include lockfiles in the default build dependencies though, since they change very often and would hurt cache hit rate. I'd prefer an opt-in: users who need stricter correctness can add pnpm-lock.yaml / yarn.lock / package-lock.json via buildCache.buildDependencies.

[escaton]

So, you think there are situations, when lock file had changed, but the build dependencies are not? can you give an example?

[chenjiahan]

Rspack already detect runtime dependency changes via the snapshot logic. For runtime dependency changes, Rspack will usually notice the node_modules changes and invalidate the relevant module cache, not rely on the lockfile itself.

[escaton]

Ok, but what about the build-time dependencies, like loaders, plugins, or rsbuild itself for example?

[chenjiahan]

rsbuild.config.* is part of the default buildDependencies. That means any modules imported from the config are also tracked by default. If they changed, the cache is invalidated automatically.

@jerrykingxyz Can you help to check this?

[jerrykingxyz]

Yes, rspack analyzes the dependencies of common files such as *.js and *.ts in build_dependencies, and treats the dependent files as part of build_dependencies as well. It's worth noting that if a dependency is located in node_modules, for performance reasons, we stop the analysis and add the current module's package.json to build_dependencies.

Relevant implementation details can be found here: https://github.com/web-infra-dev/rspack/blob/911cde3901b9305373deb227c89a745ad40d32f6/crates/rspack_core/src/cache/persistent/build_dependencies/helper/mod.rs#L138

[escaton]

Oh, that's nice. Thanks for explanation!