usage with babel-plugin-webpack-loaders #297

iam4x · 2016-07-05T17:30:23Z

Hello,

Is there anyone who made this work correctly with https://github.com/istarkov/babel-plugin-webpack-loaders ? My server code is requiring .css files to work with css-modules.

The uncovered-lines returned by nyc are completely wrong, I think it's checking webpack compiled code instead of sourcemaps but I didn't investigate that much.

Here's my babelrc:

{
  "presets": ["save"],
  "plugins": [
    "typecheck",
    "react-hot-loader/babel",
    "lodash"
  ],
  "env": {
    "test": {
      "sourceMaps": "true",
      "plugins": [
        [ "webpack-loaders", { "config": "${CONFIG}" } ],
        [ "resolver", { "resolveDirs": [ "./" ] } ]
      ]
    }
  }
}

I've also tried with babel-plugin-istanbul or babel-plugin-__coverage__ no luck.

Does anyone have a working example with all these libraries?

The text was updated successfully, but these errors were encountered:

iam4x · 2016-07-05T18:01:20Z

Now $ nyc npm test works 👍

I've added inline-source-map into my webpack config for tests and removed the configuration about babel-plugin-istanbul

Results:

It's still failing when I add --cache:

And when I add --all:

> $ nyc --all npm test                                                                         ⬡ 4.4.7 [±ava-tests ✓]

/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:5701
            throw e;
            ^
Error: Line 1: Unexpected token
    at constructError (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:2406:21)
    at createError (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:2425:17)
    at unexpectedTokenError (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:2499:13)
    at tolerateUnexpectedToken (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:2508:21)
    at parseStatementListItem (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:3972:21)
    at parseFunctionSourceElements (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:4868:23)
    at parseFunctionExpression (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:5073:16)
    at parsePrimaryExpression (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:3272:24)
    at inheritCoverGrammar (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:2680:18)
    at parseLeftHandSideExpressionAllowCall (/Users/iam4x/github/futureRX/node_modules/nyc/node_modules/istanbul/node_modules/esprima/esprima.js:3413:20)

I have zero knowledge into istanbul / nyc / coverage feel free to guide me for more debuging informations.

You can reproduce with checking out iam4x/futureRX#2

bcoe · 2016-07-05T18:02:31Z

@iam4x the cache is very contentious right now, we're doing some work around it as we gear up for a 7.x release. I'll update this issue shortly once we hammer out some conversations in a few related tickets.

bcoe · 2016-07-07T05:31:41Z

@iam4x could you try installing nyc@next I think this will potentially solve the problem you're seeing with --all. not quite sure why the cache might be biting you, any thoughts @jamestalmage?

bcoe · 2016-07-07T05:33:10Z

@jamestalmage actually, perhaps this is pid collision related?

iam4x · 2016-07-07T09:51:33Z

1.

$ nyc --all npm test AND $ nyc --cache npm test are working with nyc@next 👍

I get warnings like this one with --all :
(but it seems working as expected, files not covered are shown correctly in red)

failed to instrument /Users/iam4x/github/futureRX/app/actions/todos.js with error: 'import' and 'export' may appear only with 'sourceType: module' (1:0)

2.

I resolved the warnings by adding into my package.json nyc config:

require: [
  "babel-register",
  "babel-polyfill"
]

But after that it fails creating the report:

3.

Trying with babel-plugin-istanbul and nyc config:

"sourceMap": false,
"instrument": false

It creates an empty report:

I'll keep the first configuration for now, I can live with warnings 👍

Thank's for the support @bcoe 🍻

bcoe · 2016-07-07T15:33:47Z

@iam4x is this a project that you could share with us? I'd like to try to support all these scenarios. To give you some background, nyc grew up independently of istanbuljs and we're now in the process of smashing the two projects together -- I want to make sure the first release kicks butt.

for the approach using babel-plugin-istanbul could you try not using the --all flag? we don't yet support this feature: istanbuljs/babel-plugin-istanbul#4

would love your help getting this over the finish line: #303

iam4x · 2016-07-07T16:06:04Z

Sure, the project is available https://github.com/iam4x/futureRX

The setup is pretty easy:

$ npm install
$ npm test

Tried without --all flag I have the same behaviour:

bcoe · 2016-07-08T18:23:36Z

@JaKXz any thoughts about why @iam4x is bumping into this issue with babel-plugin-istanbul?

JaKXz · 2016-07-08T21:11:20Z

@bcoe I tried some things that worked for me before and I think the instrumentation info isn't being passed to babel-plugin-istanbul?

EDIT: realized I just gave a redundant summary of @iam4x's experiences, but I haven't tested the --all flag w/ nyc@7 or a webpack setup before.

JaKXz · 2016-07-08T22:05:56Z

That being said, @iam4x I just caught NODE_ENV=test being set ~~before~~ after you call nyc which means that babel-register won't actually call the plugins (edit: for nyc to use) you've listed in the env.test section of the .babelrc.

I've made some progress on this branch, but I've hit some webpack errors - feel free to grab it off my remote and hack away. iam4x/futureRX#4

bcoe · 2016-07-08T23:56:37Z

@JaKXz great work 👍 how are you feeling about the 7.x release at this point, I'm getting really close to dropping the hammer -- want to look into another issue that just opened first related to empty coverage reports.

JaKXz · 2016-07-09T00:47:37Z

Thanks! :')

I think 7.x isn't blocked by anything other than that empty coverage report bug too. This issue is with a webpack setup which wasn't supported in v6 either, so I'm ok with it being in a feature release (if there's a fix needed, maybe @iam4x could help with a minimal reproduction?). I also have concerns about general performance (i.e. "it feels slow but I don't think it's unbearably slow") but we I have to make time to profile / benchmark etc which would make a great feature release as well.

iam4x · 2016-07-13T15:43:09Z

Sure, I'll be happy to help and re-create a minimal reproduction case for testing purpose instead of the big boilerplate 👍

Should I do this somewhere into nyc repo as a PR?

JaKXz · 2016-07-13T16:01:25Z

@iam4x a gist works well.

iam4x mentioned this issue Jul 5, 2016

Add ava testing suite iam4x/futureRX#2

Merged

5 tasks

bcoe added this to the nyc-7 milestone Jul 6, 2016

bcoe closed this as completed Jul 17, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

usage with babel-plugin-webpack-loaders #297

usage with babel-plugin-webpack-loaders #297

iam4x commented Jul 5, 2016 •

edited

Loading

iam4x commented Jul 5, 2016

bcoe commented Jul 5, 2016

bcoe commented Jul 7, 2016

bcoe commented Jul 7, 2016

iam4x commented Jul 7, 2016 •

edited

Loading

bcoe commented Jul 7, 2016 •

edited

Loading

iam4x commented Jul 7, 2016 •

edited

Loading

bcoe commented Jul 8, 2016

JaKXz commented Jul 8, 2016 •

edited

Loading

JaKXz commented Jul 8, 2016 •

edited

Loading

bcoe commented Jul 8, 2016

JaKXz commented Jul 9, 2016 •

edited

Loading

iam4x commented Jul 13, 2016

JaKXz commented Jul 13, 2016

usage with babel-plugin-webpack-loaders #297

usage with babel-plugin-webpack-loaders #297

Comments

iam4x commented Jul 5, 2016 • edited Loading

iam4x commented Jul 5, 2016

bcoe commented Jul 5, 2016

bcoe commented Jul 7, 2016

bcoe commented Jul 7, 2016

iam4x commented Jul 7, 2016 • edited Loading

1.

2.

3.

bcoe commented Jul 7, 2016 • edited Loading

iam4x commented Jul 7, 2016 • edited Loading

bcoe commented Jul 8, 2016

JaKXz commented Jul 8, 2016 • edited Loading

JaKXz commented Jul 8, 2016 • edited Loading

bcoe commented Jul 8, 2016

JaKXz commented Jul 9, 2016 • edited Loading

iam4x commented Jul 13, 2016

JaKXz commented Jul 13, 2016

iam4x commented Jul 5, 2016 •

edited

Loading

iam4x commented Jul 7, 2016 •

edited

Loading

bcoe commented Jul 7, 2016 •

edited

Loading

iam4x commented Jul 7, 2016 •

edited

Loading

JaKXz commented Jul 8, 2016 •

edited

Loading

JaKXz commented Jul 8, 2016 •

edited

Loading

JaKXz commented Jul 9, 2016 •

edited

Loading