Do not rely on file `mtime` about cache-loader HOT 8 OPEN

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

from cache-loader.

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

from cache-loader.

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

from cache-loader.

👍 for the PR made by @LukeSheard

from cache-loader.

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?

from cache-loader.

is this fixed?

from cache-loader.

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

from cache-loader.

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

from cache-loader.