-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Node.js-style --require CLI argument #296
Conversation
That would be my approach, does not need to be fancy. // test/fixture/install-global.js
global.foo = 'bar' // test/fixture/validate-installed-global.js
import test from '../../'
test(t => t.is(global.foo, 'bar')); Then use the API to call Overall looks pretty good. |
return fork(args) | ||
var options = {}; | ||
|
||
if (Array.isArray(this.require) && this.require.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just do
if (this.require) {
// ...
}
You have already guaranteed it is an array of at least length one above.
Not sure we ever got an agreement on this:
|
I don't know if our Babel hook should be disabled automatically. I still have not decided the best way to make it all work. My current thinking is using something along the lines of #297, but using a better version of |
Unless I somehow accomplished this accidentally, I did not attempt to disable ava's babel hook. My only purpose with this PR was the pass through the Also, I hope to get time to address the PR feedback over the next few days. I'm sorry for not being very responsive. |
Understood, we are still deciding if / when / how to do that. Once a decision on that gets made we will merge this, and augment it with whatever behavior we finally decide on.
That is not a problem. We still have to answer a few questions, so we are in no rush to merge. |
I still haven't pushed tests yet. They don't seem quite as trivial as I'd hoped, even with @jamestalmage's suggestions. Soon... |
Really stuck with the testing part. I'm getting similar errors when I try to use I've tried a few simple approaches, and none of them work. But this functionality doesn't seem complicated enough to warrant a complicated test. Is there an obvious flaw in this approach? Or do I need to take this up a notch? |
Thanks for the hint, @jamestalmage. At least now, the errors are all the same one:
|
I could use mockery and just confirm that Node.js is called with the expected parameters, without actually calling Node.js? /shrug |
Well, I'm having a hard time getting this to work on travis. Test #4 seems to work on OSX. Note that the |
@sindresorhus @vdemedes - either of you develop on linux? Any advice on how he should fix this? |
So I should detect the version of Node in the tests and only run them for >=4.0? |
I don't know. Maybe it would just be better to manually implement the same semantics as the |
I have Linux in a VM, but I almost never use it, so pretty noobish with it.
👍 This is where the |
Okay, well I'll have another crack at it over the next few days. I'll try implementing |
if (this.require && !Array.isArray(this.require)) { | ||
// normalise single `--require moduleId` usage | ||
this.require = [this.require]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just use arrify
on line 69 and drop this whole thing.
requires.forEach(function (el) {
require(resolveCwd(el));
)); |
@@ -0,0 +1 @@ | |||
global.foo = 'bar' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
semicolon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird. I love my semi-colons, too. I wonder why ESLint didn't bust my chops about this? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I added 4 tests to check different argument orders, but we should probably just pick the one we like and get rid of the rest? |
@@ -16,6 +16,11 @@ if (debug.enabled) { | |||
// Bind globals first, before anything has a chance to interfere. | |||
var globals = require('./globals'); | |||
|
|||
var resolveCwd = require('resolve-cwd'); | |||
(opts.require || []).forEach(function (moduleId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think opts.require
is already guaranteed to be an array, so this check is moot.
https://github.com/sindresorhus/ava/pull/296/files#diff-2cce40143051e25f811b56c79d619bf5R73
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. In the API tests, new Api()
is called without the second parameter, which means it ends up being an empty Object, without a "require" property. Should I change the fallback default value in api.js to include an empty "require" array? e.g. this.options = options || { require: [] };
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, never mind then. I read it wrong.
Okay, so in total I have 1 api test and 1 cli test. I left the cli test in there to stress the end-to-end process a bit. Of course, if you think this is overkill then I'm happy to drop the cli test completely. |
@@ -697,4 +698,3 @@ Concurrency is not parallelism. It enables parallelism. [Learn more.](http://sta | |||
<br> | |||
<br> | |||
</div> | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't remove
I think it's overkill to CLI test all options, but I'm ok with this if you rework it into being a generic CLI option test, meaning change the test description. We should have one CLI test making sure options are passed correctly. |
I gave it a whirl, but it seemed infeasible to mock the boundary from cli.js to the others, and my other approach to CLI argument tests seemed unnecessarily complex (and still didn't work). If we still feel strongly about having CLI tests, we can have a separate Issue / PR. |
LGTM |
1 similar comment
LGTM |
Node.js-style --require CLI argument
Thank you @jokeyrhyme! :) 💥👌 Keep the quality contributions coming. We really appreciate your help. |
Thank you for your work, @jokeyrhyme! |
Hey, @sindresorhus, @vdemedes, @jamestalmage: Any idea when this might ship? I'd really prefer to not depend directly on master. Thanks! |
Thanks @sindresorhus! |
@ariporad Actually, I did a release now. https://github.com/sindresorhus/ava/releases/tag/v0.8.0 |
Yay! Thanks! |
There have been major performance improvements since this was discussed. If possible, could you give AVA a try again and tell us how we're doing? |
That's great to hear! Currently this is the biggest migration blocker for us: it's important that our tests run in the same transpilation environment as our lib code (we now use several custom Babel transforms). Our test suite is large enough (>100 files) that I'd rather not rewrite it in AVA until I know this will be possible. That said, I'd be happy to convert a couple of our tests to see what the perf looks like relative to Mocha. |
My approach to this is to transpile using See |
Wow! I would love to see a project that big converted. Is it open source? What is your current test setup? (mocha with chai for assertions, etc) You may also want to wait for customizable assertions, so we can create one that matches your current assertion api exactly. |
I think you're talking about transpiling lib code (imported by tests). This PR provides an easier way to do that: I'm talking about having test code transpiled in the same way that your lib code is, rather than letting AVA transpile it. See the comment that I linked to for more info.
Unfortunately not. I work on Kensho's front-end and we're currently using Mocha/Chai (assert style). I'd like to move to a flat Tape/AVA-style interface. We do have an open source React chart lib -- also using Mocha but faking a Tape-ish API -- that we might be able to convert as well.
I'm actually not a huge fan of our current assertions, so I don't mind rewriting them when the time comes. AVA's defaults seem great. |
I figured I'd have an attempt at being able to pass the
--require
through to the Node executable used for the child process (#229).My test project uses
import
andexport
, so doesn't execute in Node v5 without babel/register. I can manually confirm usingnpm link
that the changes I have so far function as expected.Besides general comments (very much appreciated), I'm a little bit at a loss as where to start with the tests. Do I need to confirm (with tests) that the
ava --require moduleId
works? Or is it sufficient to use mocks and confirm that arguments are being passed through as expected?