Skip to content
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

Don't try to cover the bin/nyc.js file #138

Merged
merged 3 commits into from
Jan 18, 2016
Merged

Conversation

isaacs
Copy link
Collaborator

@isaacs isaacs commented Jan 12, 2016

This makes it possible to self-test node-tap's coverage reporting and
coverage level checking when running in covered mode. Otherwise, doing
node {nycBin} check-coverage results in executing the nyc executable
script as the main file (or worse, some module named check-coverage,
which obviously doesn't exist).

This makes it possible to self-test node-tap's coverage reporting and
coverage level checking when running in covered mode.  Otherwise, doing
`node {nycBin} check-coverage` results in executing the nyc executable
script as the main file (or worse, some module named `check-coverage`,
which obviously doesn't exist).
This is a cleaner solution to the issue caused by spawning the nyc bin
from a test that is currently covered.

Also avoids having competing arg-parsing between yargs (better for
program arguments, user-flags, and such) and spawn-wrap, which just
splices off a set count of positional arguments from the array.
Checking for 'report' anywhere in the command means that something like

    nyc my-thing which-is-not-nyc report

would end up running nyc's reporter instead of my thing.
@isaacs
Copy link
Collaborator Author

isaacs commented Jan 12, 2016

Added another 2 commits with a cleaner (imo) approach.

Now coverage should not interfere with running nyc itself, and nyc can cover things with report or check-coverage in the arguments.

Still not sure why it doesn't work to cover nyc with nyc, though.

@jamestalmage
Copy link
Member

Still not sure why it doesn't work to cover nyc with nyc, though.

We moved away from that because there are just too many (potentially) overlapping parts:

  1. Multiple spawn wraps.
  2. Installing the require extension multiple times.
  3. NYC generating reports on itself (messing up tests that count the number of tests created by a test fixture)
  4. NYC_CWD environment conflicting with the one we want when we move into the fixture directory.

Too many potential traps. It's easier to just use the manual method we currently are.

@isaacs
Copy link
Collaborator Author

isaacs commented Jan 12, 2016

Fair enough.

But I still want to have node-tap be able to spawn nyc and have it able to run a report or coverage-check while coverage is enabled, so that I can get more test coverage of node-tap.

You could get around the conflicting NYC_CWD environ by not relying on an environment variable for that. If a positional argument was passed to spawn-wrap, it'd be able to have as many of those as necessary, and un-wrap at each level. Even if it was wrapped 50 times, it'd get progressively slower of course, but the wrapping would be fine, and could be using a different NYC_CWD at each level.

Nesting require extensions would be tricky, but wasn't there something in the works to support that anyway, for babel and such?

@jamestalmage
Copy link
Member

Nesting require extensions would be tricky, but wasn't there something in the works to support that anyway, for babel and such?

It's in already (append-transform).
Prior to that fix we would actually clobber the old require extension. The new behavioral actually enables/honors multiple installations (thereby creating the problem).

@jamestalmage
Copy link
Member

But I still want to have node-tap be able to spawn nyc and have it able to run a report or coverage-check while coverage is enabled, so that I can get more test coverage of node-tap.

That makes sense. This enables that, correct?

@bcoe
Copy link
Member

bcoe commented Jan 12, 2016

@jamestalmage if this pull makes it easier to test tap, I see no reason not to land it; I'd like to test thoroughly though -- requiring that report occur at position 0 now concerns me the most, probably the correct logic, but is this a breaking change now I wonder?

@jamestalmage
Copy link
Member

I'm not opposed to landing it. I was just providing background.

I haven't reviewed yet (on mobile). So I can't comment on if it's a breaking change. But if what you say is true, then yeah.

@isaacs
Copy link
Collaborator Author

isaacs commented Jan 12, 2016

requiring that report occur at position 0 now concerns me the most, probably the correct logic, but is this a breaking change now I wonder?

Yargs will already pull out --flags from the _ array. So this would only change nyc check-coverage report from being a report command to a check-coverage command, and allow running things like nyc npm run report for example.

@jamestalmage
Copy link
Member

LGTM.

I like the use of wrap.js.

@isaacs
Copy link
Collaborator Author

isaacs commented Jan 17, 2016

@bcoe lgty?

@bcoe
Copy link
Member

bcoe commented Jan 18, 2016

@isaacs smoke tests look good, merging; I'll let you know once a release has gone out.

bcoe added a commit that referenced this pull request Jan 18, 2016
Don't try to cover the bin/nyc.js file
@bcoe bcoe merged commit 445f44b into istanbuljs:master Jan 18, 2016
@bcoe
Copy link
Member

bcoe commented Jan 21, 2016

@isaacs if you give the next branch of nyc a spin, this work is now landed:

npm i nyc@next

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants