Webpack filesystem cache questions

[Armine-i]

Hi Webpack team 👋 ,

I have some questions regarding the use of the filesystem cache feature.
For context, these questions relate to adding filesystem caching to our production builds. Thank you for taking the time to review them!

1. In the default config setting (config: [__filename]), are transitive dependencies from our codebase included along the entire dependency tree? For example, does this include imports of the imports used in the Webpack configuration file? (via require())
2. How are loaders and plugins included in the cache? How does invalidation work?
   If we use custom loaders that are referenced dynamically (e.g., via path.resolve), should we explicitly track these dependencies, along with any other dynamic imports? For example:
   loader: path.resolve(baseDirPath, 'webpack/loaders/json-loader.js'),
3. Should build orchestration scripts that invoke the Webpack CLI be included as build dependencies? I believe these docs suggest they should, but I wanted to confirm.
4. Would you recommend adding package.json & yarn.lock as a dependency, as a way to track npm dependency changes? For example like so:

dependencies: [
    path.resolve(baseDirPath, 'package.json'),
    path.resolve(baseDirPath, 'yarn.lock'),
]

5. Webpack CLI arguments and environment parameters passed via the CLI would invalidate the cache if their values change, correct?
6. Do you have any recommended strategies for optimizing cache generation in a multi-environment setup (e.g., dev, QA, prod)? Specifically, are there best practices for cache clearing in CI pipelines, setting an age limit, and how hashes compare to timestamps? (we've currently configured hash: true for CI)
7. Is there a way to implement partial cache invalidation for files that we know will be rewritten (e.g., HTML generated by HtmlWebpackPlugin), rather than invalidating an entire cache pack?

[alexander-akait]

Sorry for long delay, really a lot of issue

In the default config setting (config: [__filename]), are transitive dependencies from our codebase included along the entire dependency tree? For example, does this include imports of the imports used in the Webpack configuration file? (via require())

Yes, we parse your files and include any import/require as a dependecies

How are loaders and plugins included in the cache? How does invalidation work?
If we use custom loaders that are referenced dynamically (e.g., via path.resolve), should we explicitly track these dependencies, along with any other dynamic imports? For example:
loader: path.resolve(baseDirPath, 'webpack/loaders/json-loader.js'),

You can use as you wish, we store snapshot of each dependency in your configuration (i.e. timestamp and hash of content), so if timestamp or hash was changed we will invalidate this cache (and so any files which import this file).

Should build orchestration scripts that invoke the Webpack CLI be included as build dependencies? I believe these docs suggest they should, but I wanted to confirm.

Yes, you need to pass all dependencies (paths) which may change your build, by default webpack-cli includes only webpack.config.js (to be more precise, the configuration file that you use during bundling)

Would you recommend adding package.json & yarn.lock as a dependency, as a way to track npm dependency changes? For example like so:

There is no need to do this, webpack by default tracks your dependencies from node_modules (which you used in your code), to control it we have the snapshot.managedPaths option (by default it is node_modules regexp).

Webpack CLI arguments and environment parameters passed via the CLI would invalidate the cache if their values change, correct?

Yes, because the configuration file will be changed

Do you have any recommended strategies for optimizing cache generation in a multi-environment setup (e.g., dev, QA, prod)? Specifically, are there best practices for cache clearing in CI pipelines, setting an age limit, and how hashes compare to timestamps? (we've currently configured hash: true for CI)

Sorry, no, different CI often require different settings, it is best to just try and check that the cache is not invalidated/invalidated.

We have couple example here - https://webpack.js.org/configuration/cache/#setup-cache-in-cicd-system

Is there a way to implement partial cache invalidation for files that we know will be rewritten (e.g., HTML generated by HtmlWebpackPlugin), rather than invalidating an entire cache pack?

We never invalidate entire cache pack, only things which were changed, if we were more precise, we use two caches by default ${name}-${mode} where name is the name of your configuration (https://webpack.js.org/configuration/other-options/#name) and mode - https://webpack.js.org/configuration/mode/

Feel free to feedback