New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the `import-local` module #1376

Merged
merged 2 commits into from Jun 14, 2017

Conversation

Projects
None yet
2 participants
@sindresorhus
Member

sindresorhus commented May 4, 2017

https://github.com/sindresorhus/import-local

I've used this method in a few other projects, so I thought I might as well make a module out of it.

I could use some feedback on the approach too: https://github.com/sindresorhus/import-local/blob/87a0c91a9a0ecea64471a95479b0366af296b989/index.js#L7-L10

I'm aware the existing test for this is failing. I was not sure how to properly mock this as I don't think you can use proxyrequire on sub-dependencies. @novemberborn Any suggestions?

@sindresorhus sindresorhus requested a review from novemberborn May 4, 2017

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn May 6, 2017

Member

I could use some feedback on the approach too

Approach seems good. I like how you take the relative path from the potential global directory, and then map it to a local import.

I'm aware the existing test for this is failing. I was not sure how to properly mock this as I don't think you can use proxyrequire on sub-dependencies. @novemberborn Any suggestions?

We could stub import-local and see if the CLI code handles the return value correctly. Alternatively if you want more of an integration test I think you'll have to use fixtures to set up a "global" AVA and then see if it picks up the local version.

Member

novemberborn commented May 6, 2017

I could use some feedback on the approach too

Approach seems good. I like how you take the relative path from the potential global directory, and then map it to a local import.

I'm aware the existing test for this is failing. I was not sure how to properly mock this as I don't think you can use proxyrequire on sub-dependencies. @novemberborn Any suggestions?

We could stub import-local and see if the CLI code handles the return value correctly. Alternatively if you want more of an integration test I think you'll have to use fixtures to set up a "global" AVA and then see if it picks up the local version.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn May 10, 2017

Member

I think if you create a fixture directory that contains a node_modules/ava/cli.js file then that file will be treated as the local file, assuming you execCli() with dirname set to that fixture directory. From inside the cli.js file you could just do require('../../../../cli') and it'll execute normally (I didn't count the ../ so this may not be accurate).

At this point running the normal cli.js from execCli gives you global, and with the correct dirname it should switch to local.

This should replace

ava/test/cli.js

Lines 408 to 436 in 2ed9485

test('prefers local version of ava', t => {
t.plan(1);
const stubModulePath = path.join(__dirname, '/fixture/empty');
const debugSpy = sinon.spy();
const resolveCwdStub = () => stubModulePath;
function debugStub() {
return message => {
let result = {
enabled: false
};
if (message) {
result = debugSpy(message);
}
return result;
};
}
proxyquire('../cli', {
debug: debugStub,
'resolve-cwd': resolveCwdStub
});
t.ok(debugSpy.calledWith('Using local install of AVA'));
t.end();
});
.

Member

novemberborn commented May 10, 2017

I think if you create a fixture directory that contains a node_modules/ava/cli.js file then that file will be treated as the local file, assuming you execCli() with dirname set to that fixture directory. From inside the cli.js file you could just do require('../../../../cli') and it'll execute normally (I didn't count the ../ so this may not be accurate).

At this point running the normal cli.js from execCli gives you global, and with the correct dirname it should switch to local.

This should replace

ava/test/cli.js

Lines 408 to 436 in 2ed9485

test('prefers local version of ava', t => {
t.plan(1);
const stubModulePath = path.join(__dirname, '/fixture/empty');
const debugSpy = sinon.spy();
const resolveCwdStub = () => stubModulePath;
function debugStub() {
return message => {
let result = {
enabled: false
};
if (message) {
result = debugSpy(message);
}
return result;
};
}
proxyquire('../cli', {
debug: debugStub,
'resolve-cwd': resolveCwdStub
});
t.ok(debugSpy.calledWith('Using local install of AVA'));
t.end();
});
.

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Jun 13, 2017

Member

@novemberborn Thanks for the tips. Should be good now.

Member

sindresorhus commented Jun 13, 2017

@novemberborn Thanks for the tips. Should be good now.

@sindresorhus sindresorhus merged commit 7c62b35 into master Jun 14, 2017

6 checks passed

codecov/patch 100% of diff hit (target 96.99%)
Details
codecov/project Absolute coverage decreased by -<.01% but relative coverage increased by +3% compared to dfca2d9
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
dependency-ci Dependencies checked
Details

@sindresorhus sindresorhus deleted the import-local branch Jun 14, 2017

kevva added a commit that referenced this pull request Sep 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment