Do not rely on file mtime

[jdeniau]

npm 5.8+ set file mtime to October 1985 (See npm/npm#20439 ), it's a feature for them, so the cache-loader does not work anymore.

Furthermore, f24f723 tells to not trust file mtime.

Should we relly on file content hash instead ?

[alexander-akait]

@jdeniau need tests mtime vs md4 from hash content. PR welcome 👍

[LukeSheard]

Maybe this could be slightly more generic, can supply a custom compare function for the comparison callback?

[luislobo]

👍 for the PR made by @LukeSheard

[bencoveney]

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]

is this fixed?

[alexander-akait]

@sibelius no, cache-loader is low priority due webpack@5 will have built-in cache, anyway if you want to fix something PR welcome

[jdeniau]

For the record, I do not use cache-loader anymore, as webpack does a fine job now like @evilebottnawi said.

[scottrippey]

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