-
-
Notifications
You must be signed in to change notification settings - Fork 359
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
feat: nyc is being refactored to become the official Istanbul 1.0 bin #286
Conversation
one thing I've noted, is that the final bundled nyc balloons from 3MB to 7MB. On the plus side, since it's bundled it comes down as a single As we discussed, a good chunk of this size is in 16K append-transform
16K arrify
164K caching-transform
72K convert-source-map
52K default-require-extensions
56K find-cache-dir
68K find-up
560K foreground-child
308K glob
108K istanbul-lib-coverage
57M istanbul-lib-instrument
384K istanbul-lib-report
5.4M istanbul-reports
52K md5-hex
672K micromatch
156K mkdirp
16K pkg-up
16K resolve-from
24K rimraf
24K signal-exit
784K source-map
304K spawn-wrap
1.0M test-exclude
1.9M yargs Specifically the babel tool-chain: 12M ./babel-generator
12M ./babel-template
13M ./babel-traverse
12M ./babel-types
7.8M ./babylon Currently we bundle |
package size updateIf I bundle using an testing updateI've published the new
|
I'm seeing some issues with the ava test suite, using the new instrumentation approach: not ok should match pattern provided
found: >
/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/location.js:25
throw err;
^
SyntaxError: 'return' outside of function (14:1)
at Parser.pp.raise (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/location.js:22:13)
at Parser.pp.parseReturnStatement (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:321:10)
at Parser.pp.parseStatement (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:107:19)
at Parser.pp.parseBlockBody (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:529:21)
at Parser.pp.parseBlock (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:510:8)
at Parser.pp.parseStatement (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:127:19)
at Parser.pp.parseIfStatement (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:314:26)
at Parser.pp.parseStatement (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:105:19)
at Parser.pp.parseBlockBody (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:529:21)
at Parser.pp.parseTopLevel (/Users/benjamincoe/bcoe/coverage/ava/node_modules/nyc/node_modules/babylon/lib/parser/statement.js:36:8) @jamestalmage @novemberborn any thoughts? |
It looks like you probably need to enable the |
@jamestalmage just came to that conclusion myself, got tests running by removing returns in the top-level cli module, I'll go ahead and set that configuration option. great find! |
instrumented = instrumenter.instrumentSync(code, filename) | ||
} catch (e) { | ||
// don't fail external tests due to instrumentation bugs. | ||
console.warn('failed to instrument', filename, 'with error:', e.message) |
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.
Any way to configure this to prevent it from logging? Could there be a scenario where this happens and cannot be easily prevented? If so, this log would be annoying/distracting noise.
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.
@kentcdodds my gut was annoy people while we're in the early phases of v7
, get bug reports, and fix quickly -- there are a few more knobs and dials it looks like we can turn in babylon.
If you think this strategy might annoy people too much, I could definitely be convinced to drop the log message.
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.
Let's wait until it becomes a problem I think 👍
added a test for native ES6 support, found a few interesting edge-cases but in general, things seem to be working a lot better: I could not get this to instrument: let a = 33 || () => {
console.log('missed')
} CC: @gotwarlost ^ we should probably put a test around this. |
@bcoe just tried Interestingly, the errors look similar to what I was getting with the current instructions using the |
On the subject of https://github.com/istanbuljs/istanbul-lib-instrument/blob/master/v0-changes.md |
On the
|
@bcoe - great progress so far. We need to figure out - if the istanbul-cli is gone - what happens to commands needed for testing on the browser (e.g. |
I think
|
|
Ran tests for a couple of my packages with |
I'm a little afraid to actually drop the hammer, but:
If folks could take one more day to hammer on this (CC: @istanbuljs/nyc) I think we'll land it. |
After /Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:32
writer.println('FN:' + [meta.decl.start.line, meta.name].join(','));
^
TypeError: Cannot read property 'start' of undefined
at /Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:32:42
at Array.forEach (native)
at LcovOnlyReport.onDetail (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:30:28)
at LcovReport.(anonymous function) [as onDetail] (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-reports/lib/lcov/index.js:21:24)
at Visitor.(anonymous function) [as onDetail] (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:34:30)
at ReportNode.Node.visit (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:123:17)
at /Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:116:23
at Array.forEach (native)
at visitChildren (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:115:32)
at ReportNode.Node.visit (/Users/kdodds/Developer/paypal/p2pnodeweb/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:126:5) Works fine with latest. |
@kentcdodds don't suppose you might be able to make a reproduction case, and tack it onto an issue? I'm holding off on merging this until we address a couple similar issues that have cropped up. @gotwarlost saw some patches landing regarding crashers/performance. Just let me know any code reviews/implementation work you need done. |
istanbul v1 now adds a new location called That's the reason the |
@gotwarlost would retiring nyc's sourcemap handling for istanbul's solve this issue? |
possibly. We need to compare if there is any difference in processing between the two. |
… for the actual bump
…ly by old Istanbul
@gotwarlost I pulled in
Other than that, I think we're pretty on track for landing this? |
Re: my "better --all" support, I'm having second thoughts about this. It may not be "better" :) Problem is the babel cache. If we process a file for side-effects only then only the preamble gets written to the babel cache because we basically nuke the real code, which is going to have all sorts of fun implications when the user goes about exercising that code later and "nothing works". If the caching were smarter to allow inclusion of the extra parameters in the cache key, it would be fine but previous comments seemed to indicate that the caching in babel is naive. |
I have been poking around in the babel code recently. I think the cache only applies to |
@jamestalmage - when the babel plugin is used, it does not control any babel-specific options (the library API will not have issues since we use |
Although if we are disabling the babel cache in nyc this might work. Just not sure how we plan to implement the |
Hey, if this has been previously mentioned apologies - I had a project recently where I wanted to use nyc but ended up at the older istanbul bin primary for the ability to run coverage to a JSON file and then run istanbul report after the fact. This was for a node lib that had been packaged for the browser with browserify - I found that command pair immensely useful to get browser coverage over the library. I think I also used the browserify-istanbul transform. Just mentioning in case you needed someone to speak up for the use case. And lastly, hank you ever so much for tools. AJB |
This refactoring work moves nyc towards using Istanbul's more modular
v1.0
API.Features of Note
istanbul
bin for the featurecheck-coverage
(calculating this is now our responsibility)..istanbul.yml
, we will extend nyc's configuration gradually to support any configuration options that we're missing.babel-plugin-istanbul
for ES6/ES7 support.--all
functionality, using an approach closer to what istanbul's original bin used:Breaking Changes
.istanbul.yaml
is no longer supported.instrumenter
configuration option for the time being (I think we get pretty far with the new istanbul-lib-instrument, and a noop instrumenter, and can avoid abstracting this part of the API for the time being).Todo
[email protected]
published.- [ ] get --all working withwe can address this separately._babel-plugin-istanbul
.CC: @novemberborn, @jamestalmage, @dtinth, @gotwarlost