(Yet another) "import and bypass Node's require.cache" package. This one, however, restores the cache to its prior state after fetching a unique copy of the provided module, making it unobtrusive.

Install

$ npm i @darkobits/import-unique

Use

This package's default export is a function with the following signature:

type importUnique = (module: string): any;

The function will temporarily remove the resolved module from Node's cache, require() it, restore the cached version, and return the unique version.

i-can-haz.js

let canHaz = false;

// Something that operates on shared mutable state.
export default function toggleCanHaz() {
  canHaz = !canHaz;
  return canHaz;
}

a.js

import canHaz from './i-can-haz';

console.log(canHaz()); // => true

b.js

import canHaz from './can-haz';

console.log(canHaz()); // => false

Because i-can-haz relies on shared mutable state, b.js is now a sad panda, as it clearly cannot haz, and may or may not know/care that it cannot haz because a.js already haz. We generally want to avoid writing our modules this way, so as to ensure that everyone can haz. Sometimes, however, we may have to work with a module we don't control. Bypassing Node's module cache is a reasonable way to ensure everyone who wants to haz... can haz.

a.js

import importUnique from '@darkobits/import-unique';

const canHaz = importUnique('./i-can-haz');

console.log(canHaz()); // => true

b.js

import importUnique from '@darkobits/import-unique';

const canHaz = importUnique('./i-can-haz');

console.log(canHaz()); // => true

N.B. If there are other modules importing i-can-haz normally and, in fact, expect the shared mutable state behavior it uses, they may continue to do so. Modules that import the shared copy of i-can-haz after a unique copy has been imported will continue to get the same shared copy of the module. In this way, import-unique is completely unobtrusive and everyone can haz what they want.