novemberborn / cached-module-loader Goto Github PK

I think the API for that module could be simple and export only one factory function, which returns a modified require():

const cachedRequire = require('cached-module-loader'){
  cachePath: join(__dirname, '.module-cache'),
  ignore: [/regex/, /to/, /ignore/]
});

const babel = cachedRequire('babel-core');
const got = cachedRequire('got');

cachedRequire()'s source would be something along:

function cachedRequire(moduleId) {
  if (!isCacheExists(moduleId)) {
    bundleDependencies(moduleId);
  }

  return loadInThisContext(moduleId);
}

What do you think?

• From the perspective of the module, it shouldn't really be able to tell whether it was loaded from a cache or through Node.js module system. This means that all properties on the module object must be the same (aside from module.parent).
• Circular dependencies must work as expected
• Depending on built-in modules must work as expected
• Dynamic requires are not cached, but must still resolve
• …?

It's ridiculously slow for this use case.

The cachedData Script API is only supported in Node.js v6. This module should probably work with older Node.js versions, even without cachedData.

Module caches may include lots of files. These are dependent on file system location, Node.js version, and indeed package version. This package should explain appropriate caching strategies.

I reckon that the cache should be discarded when the Node.js version changes. Perhaps we should generate a cache key that takes the version into account, allowing caches for different versions to live side-by-side.

The cache contains hardcoded file paths, so we need an easy way to verify the presumed location of the sources.

Integration with package-hash should be easy.

Perhaps we can resolve the npm modules the cache depends on. Then the respective package.json files could be hashed and verified before using the cache.