Add readonly mode for filesystem cache
See original GitHub issueFeature request
Add readonly
mode for filesystem cache to outcome shared cache missing limitation
What is the expected behavior?
It should be possible to use already existing cache without tackling problems of concurrent write access, handling unused entries and managing uncontrolled grow of cache.
What is motivation or use case for adding/changing the behavior?
This will allow reuse at least common node_modules cached entries when running multiple compilations in parallel.
To clarify situation, where it’s need:
- Project is monorepo with several (or more) packages where every one of them is compiled to single js file. Packages are quite big (result file is about 1-2 Mb). node_modules are hoisted to root and can be effectivly cached between all packages.
- Build is almost always production and not in watch mode.
- We need to somehow reduce compilation time of all packages. Especially in CI.
- Separate cache for every package is not efficient in terms of time: in CI it’s not helping and memory: we have server and client builds and cache for them is about 100 Mb for one package
- Multiple entries not share they memory cache (at least that what it’s looks like when i try that) and even result to build hang.
So this solution looks pretty light and bring our build with webpack 5 to be at least not slower than with webpack 4, which, in turns, will allow us to move to webpack 5.
How should this be implemented in your opinion?
Flag cache.readonly
in config, which is disable cache store in store method of PackFileCacheStrategy
Are you willing to work on this yourself? yes
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:13 (10 by maintainers)
Top GitHub Comments
You can implement this using custom plugin
I’d like to share our use case on this issue. We have a single application that builds multiple times with different flags. This is what I do: build the
base
version on its own (so it can write cache into the fs), then parallelly build the rest targets (they share the cache). The problem is those parallel builds will try to write the file system cache.Happy to see this fixed, thanks!