Dodge node's require cache

[airhorns]

requirefire intentionally re-creates the entire require stack such that when used, its as if the returned require function is from a totally different process. Two requirefire instances should be totally independent, with different require caches. Crucially, if the files on disk change between the creation of one instance and the next, the second instance should reflect those changes.

Before this change, that wasn't the case in a particular circumstance that burned us in Gadget. Specifically, if a module was required by require fire, and that module required another module from it's node_modules directory, subsequent requirefire instances requiring the entrypoint module will always get the same copy of the node_modules module, regardless of if it changes.

An example:

• const a = requirefire();
• a("foo") requires "@gadgetinc/api-client-core" from foo's node_modules, gets one copy of api-client-core
• we change api-client-core in the node_modules on disk
• const b = requirefire();
• b("foo") requires "@gadgetinc/api-client-core" again, should return the new copy, but didn't.

The reason the old copy was returned by new instances of requirefire is that there was another cache inside the node internals that all requirefire instances were sharing by accident: Module._pathCache.

The path cache is used by node to cache resolutions from entrypoints to files on disk. Usually in node the path cache is only ever filled and never emptied, and thus node will never pick up new or changed resolutions after the first time they are run. We explicitly want the opposite with requirefire, so we need to change to using one path cache per requirefire instance instead of one shared one.

Super regrettably, this shared global cache is baked in deep to node. I couldn't figure out any way to re-use node's internal logic while still changing the semantics of which path cache is used, so I had to skip node's resolve stuff that uses that cache entirely. Luckly, there's a great userland re-implementation of resolving in webpack that we can use, that has great support for ... everything. As webpack would need!