Proxyquire merges together files with the same relative path.

[jwalton]

Directory structure:

  ./index.js
  ./a/index.js
  ./a/util.js
  ./b/index.js
  ./b/util.js

Files:

// ./index.js
const proxyquire = require('proxyquire');
proxyquire('./a/index.js', {"./util": {c: "c"}});

// ./a/index.js
const util = require('./util');
require('../b');

console.log(util);

// ./a/util.js
exports.a = "a";

// ./b/index.js
const util = require('./util');

// ./b/util.js
exports.b = "b";

Expected behavior:

index.js requires ./a/index.js via proxyquire, and overrides the propery c of './util.js. Since a/util.jsdefines a propertya, we would expect the console.log()in./a/index.js` to print:

{c: 'c', a: 'a'}

Actual behavior:

{ c: 'c', a: 'a', b: 'b' }

Every time any file does require('./util'), proxyquire requires the file, and merges it together into one giant object. This does bad things if you have two different files with the same name, that both contain the same property (which is pretty common in ES6 land, where we often export default ...).

[jwalton]

If you modify ./index.js to look like:

const proxyquire = require('proxyquire');
require('./b/index.js');
proxyquire('./a/index.js', {"./util": {c: "c"}});

Then it prints:

{c: 'c', a: 'a'}

because b/index.js ends up in the node.js cache. O_o

[bendrucker]

There are other issues about confusion around caching. We're aware of that, it's something I'm interested in budgeting time to look at.

The first example is pretty surprising though. Two modules with the same basename but different absolute paths shouldn't really bear any relationship to each other.

I'll definitely keep this open but may not have time in the immediate future to debug.

[jwalton]

I'm going to take a stab at a PR for fixing this tomorrow. The problem is right here. When we index into stubs[path], path here is the relative path, and it should be the absolute path (in this case).

I'll see if I can put some time towards a PR tomorrow. Basically, though, in _withoutCache() we want to walk through stubs and resolve the full path of any key that starts with a '.' (we don't want to fully resolve modules like "react", I think, because there could be multiple versions installed, and we probably want to mock out all of them, but we do want to mock our relative paths). And then in _require(), we want to do the same for the passed in path.

(And this is for my benefit when I'm writing this tomorrow, but in both cases I think we want require('path').resolve(p.dirname(module.filename), path). Might want to rename the local variable path so it doesn't shadow the global one.)

May want to make this a major revision number, since this is theoretically a breaking change, although I'd hate to be someone who relies on this weird behavior. :P

[bendrucker]

Very happy to review a PR. _withoutCache is resolving the stub requires to absolute paths (resolve.sync). So it shouldn't be necessary to add all that path resolution code. Maybe the path resolution needs to be moved up though.