feat: add cache invalidation

[ArgonAlex]

This is a really great idea. However, there is an important issue that should be mentioned before anyone uses this in a production environment. At the very least there should be a big bold warning in the readme. Currently, this loader is assuming that the output of all affected loaders is going to remain the same forever for any given input. But updating packages from npm, or modifying options for the loaders can easily change this. To make matters even worse, some loaders read from configuration files for their options (e.g .babelrc). Basically, anything in the build environment that can potentially change the output of a loader needs to be included in the cache key. This is hard to solve generically for all loaders, because you don't know what a loader could be using that could affect its output.

A partial (but not easily usable) solution is to intelligently include what we can in the cache key (e.g webpack version and loader version/options for each cached loader). And then anything else will have to be manually added by the user.

Let's take babel-loader for example. It actually already has its own disk caching, and according to the readme their cache key by "default is a string composed by the babel-core's version, the babel-loader's version, the contents of .babelrc file if it exists and the value of the environment variable BABEL_ENV with a fallback to the NODE_ENV environment variable." So the user would have to tell cache-loader about the babel-core version, .babelrc contents and BABEL_ENV/NODE_ENV.

So this is not so great. The actual good solution to this problem would be to make disk cached loaders a standard thing within webpack. Then loader developers would be responsible for telling webpack about their cache dependencies and the user wouldn't have to do anything. That is the dream!

[mikegreiling]

It looks like https://github.com/mzgoddard/hard-source-webpack-plugin is a good alternative with more options for fine-tuning cache invalidation.

[alexander-akait]

But updating packages from npm, or modifying options for the loaders can easily change this.

• updating packages from npm.
  Agree, need search solution.
• modifying options - your get other digest for changed option for loader, we get remainingRequest, he looks like

/path/to/node_modules/css-loader/index.js?{"import":true,"sourceMap":true,"importLoaders":1}!/path/to/node_modules/postcss-loader/lib/index.js?{"sourceMap":true}!/path/to/node_modules/sass-loader/lib/loader.js?{"includePaths":["/path/to/src"],"outputStyle":"expanded","precision":8,"sourceMap":true}!/path/to/src/containers/admin/admin.scss

All options in remainingRequest string, so everything is fine.

• from configuration files
  Agree, also need search solution.

[alexander-akait]

The actual good solution to this problem would be to make disk cached loaders a standard thing within webpack.

Unfortunately this reduces performance, only slow loaders should be cached.