Open dchambers opened 9 years ago
Based on this comment, it may well make sense to make the API for this library compatible with either proxyquire or rewire.
One of the nice things about both proxyquire and rewire is that they don't modify global state like sub-realms do — good because this has been a source of problems with sub-realms. Instead, both libraries allow a test to require a special test version of a module, where some or all of the dependencies are replaced with stubs.
For example, in proxyquire you might write:
var proxyquire = require('proxyquire');
var component = proxyquire('./component', {dep: StubDep});
and in rewire you might write:
var rewire = require("rewire");
var component = rewire('./component');
component.__set__("dep", StubDep);
The main limitation to this approach is that only immediate dependencies of modules directly under test can be manipulated. However, this limitation may well never be a problem for us, and so I'd suggest we delay all work on this issue until we've converted the BRJS & CT libraries, and gained some implementation experience.
As for #1467, it will still need an API that allows modules to be overriden globally so we can implement #1469, but then it may need to be extended further to allow the creation of new modules with altered dependencies.
The MockableSystemJS library specified in #1467 will provide an API that matches what SystemJS itself provides, but it will also make sense to offer a more high level API closer to what browser-modules used to provide with its sub-realms feature.