cache-loader
cache-loader copied to clipboard
webpack-contrib
Do not rely on file `mtime`
npm 5.8+ set file mtime to October 1985 (See https://github.com/npm/npm/issues/20439 ), it's a feature for them, so the cache-loader does not work anymore.
Furthermore, https://github.com/webpack-contrib/cache-loader/commit/f24f723 tells to not trust file mtime.
Should we relly on file content hash instead ?
@jdeniau need tests mtime vs md4 from hash content. PR welcome :+1:
Maybe this could be slightly more generic, can supply a custom compare function for the comparison callback?
My diagnosis might not be correct, but I think this problem is impacting us as well. We have some custom loaders in our project written in TypeScript. When we run a build, we compile the TypeScript to JavaScript before running webpack - giving the custom loaders a new mtime. The loaders are added as dependencies by cache-loader, thus we can never get cached content.
Any chance the PR from @LukeSheard could be revived?
@sibelius no, cache-loader is low priority due webpack@5 will have built-in cache, anyway if you want to fix something PR welcome
For the record, I do not use cache-loader anymore, as webpack does a fine job now like @evilebottnawi said.
I attempted to workaround this by comparing based on ctime, but unfortunately only mtime is stored in the cache.
So ultimately, I went with the approach recommended in webpack's docs: use a postinstall hook to remove the node_modules/.cache/cache-loader folder.
https://webpack.js.org/guides/build-performance/#persistent-cache
