better handling of relative paths

[afeld]

An example:

// src/dependency.js
throw new Error("Shouldn't be required!");


// src/mocked.js
require('./dependency');


// test/mockery_test.js
var mockery = require('mockery');
mockery.enable();
mockery.registerMock('../src/dependency', {});
var mocked = require('../src/mocked');

Running node test/mockery_test.js will throw the Error. It would be great if registerMock() recognized paths as being relative to the test file (where the mock is coming from), rather than relative to the file that will require them. Does that make sense?

[davglass]

This may be "ok" in some instances, but mockery was designed to work off a "perfect match" so that it's not trying to play guessing games on what module to mock out.

We call this behavior out in the readme: https://github.com/mfncooper/mockery#registering-mocks

module, the name or path of the module for which a mock is being registered. This must exactly match the argument to require; there is no "clever" matching

[afeld]

I understand... just seems like a pretty big limitation, and one that doesn't require too much cleverness to work around.

[davglass]

I'm looking into it now, when mockery was designed the node module code was way simpler I think they have added better resolving methods since this was done.

Now that I have the tests updated, I'll see about merging the PR for this (which breaks several of my current tests).

[gotwarlost]

I've been wanting this functionality for a while. It's a breaking change so please update the major version :)

[3den]

Any update on this? I am looking forward for this update.

[davglass]

It's on my list, I'm looking into the best solutions now.

[3den]

:+1:

[jeffkole]

+1

[mikefarah]

+1 Had an issue today where we are mocking out one of our relative dependencies './parser' but we did not want to mock out a library 'handlebars'. The problem we found is that handlebars has its own './parser' and so that one is also mocked which breaks 'handlebars' :(