fix(webpack): add cacheProvider to support customized cache

[malash]

Motivation

This PR try to fix #881 . This PR is mainly inspired from a281440

Summary

This PR add a new option cacheProvider for Linaria loader.

• cacheProvider: undefined | string | ICache (default: undefined):
  By default Linaria use a memory cache to store temporary CSS files. But if you are using this loader with thread-loader you should use some consistent cache to prevent some unexpected issues. This options support a ICache instance or a path to NodeJS module which export a ICache instance as module.exports

  interface ICache {
    get: (key: string) => Promise<string>;
    set: (key: string, value: string) => Promise<void>
  }
  

Test plan

I run yarn build in this repo and copied libs folder to my Linaria project's node_modules/linaria folder.

[Anber]

Hi @malash!
Thank you for the pull request!

By pulling back filesystem-based cache we are pulling back all the problems with detecting the project root and the cache directory. I'm thinking… maybe we can just introduce a cache option, instead of cacheType? It can be an implementation of a simple interface like interface ICache { get: (key: string) => string; set: (key: string, value: string) => void }. The default implementation will be an empty Map, but it can be replaced with whatever you want: mock, filesystem or even Redis (if someone wants to use distributed build :)). What do you think?

[malash]

@Anber Good idea.

I think the interface should be async. Because async fs provide better performance than sync fs, and Redis might only support async API. And to implement the feature, the Webpack loader should be refactored with async loader.

interface ICache { 
  get: (key: string) => Promise<string>;
  set: (key: string, value: string) => Promise<void>
}.

If ok, I can refactor the PR.

[malash]

@Anber I realized there might be another problem if we chose the ICache plan.

In my case I want to use Linaria with thread-loader, and thread-loader always serialize the loader context for cross-thread communication. Unfortunately functions cannot be serialized, so this plan still cannot solve the problem #881 .

How about implementing the cache option like this:

cache: 'memory' | 'filesystem' | ICache;

It should be scalable enough ( even someone want to use Redis-based distributed build ).

[Anber]

cache: 'memory' | 'filesystem' | ICache;

It still requires find-yarn-workspace-root and other hacks…
Maybe instead of cache implementation, we can specify a path to a file/module with implementation? It would be serializable.

[malash]

@Anber I refactored the PR, could you please take a look?

I tested this branch in my project and it works.

[Anber]

@malash thank you for your awesome work!

[Anber]

I'll publish it as 2.3 later today.

[Anber]

Released