Add ability to whitelist/blacklist modules that should (not) be decached

[mihkeleidast]

This is somewhat related to #29 but a more specific feature request so filing it separately.

I'm running into some issues with decache uncaching instances of react and react-dom, so I'm getting errors like:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:

You might have mismatching versions of React and the renderer (such as React DOM)

I'm really guessing here, but it seems that deleting and re-requiring react causes some identity change for the library and... just ruins everything :)

This is most probably a very specific issue related to my dev environment, but I can pretty safely say that I do not need to uncache these modules (nor some other third party dependencies) since I'm not actively working on them.

Proposed syntax:

decache('./path/to/module', {
    // specify only which modules should be uncached,
    // child odules not matching these regex patterns should NOT be uncahced
    whitelist: [
        /node_modules\/react/,
        /node_modules\/react-dom/
    ],
    // specify which modules should NOT be uncached,
    // all other child modules should be uncached
    blacklist: [
        /node_modules\/react/,
        /node_modules\/react-dom/
    ]
});

[nelsonic]

@risker good suggestion.
But decache only removes the modules that we explicitly tell it to,
so unless you are removing react and react-dom, they should not be removed.

[mihkeleidast]

@nelsonic decache removes all child dependencies from the cache, too. If the file I'm trying to uncache is dependent on react/react-dom, they get removed.

[nelsonic]

right, that's what I was trying to understand ... if one of the dependencies is requiring and thus "decaching" react then, yes it will be removed. in which cast the "whitelist" could make sense. 👍

I don't quite see the use case for the "blacklist" though ... surely if a module is not listed in the whitelist it would always be decached, isn't that the desired behaviour? 💭

We could implement the whitelist functionality quite easily but we need to have a very clear acceptance criteria so that we can write the tests. 📝

[mihkeleidast]

Yeah.

I initally thought about the blacklist as the opposite of whitelist - so that all modules that do not match the regex patterns get uncached.

So that:

1. if whitelist nor blacklist are specified, uncache all child dependencies
2. if whitelist is specified, uncache only the dependencies that do not match the regex patterns
3. if blacklist is specified, uncache only the dependencies that do match the regex patterns, keeping all other deps intact.

I really don't need both, only one of them. I'm trying to apply this to a lerna monorepo which means that many modules depend on other modules that are in my direct control, but exist (symlinked) in the node_modules directory.

So, with:

1. whitelist, I could specify the modules that do not need to be uncached, e.g. react and react-dom and other third party deps that cause issues
2. blacklist, I could specify the modules that do need to be uncached, e.g. all local monorepo dependencies

For me, the AC would be:
if a regex pattern in the whitelist option matches a child depency of the module I'm trying to decache, do not decache that module.