I can't get sourcemaps to work with nyc, babel and mocha

[pghalliday]

Here is an example of what I am trying to do https://github.com/pghalliday/nyc-babel-mocha-sourcemaps

If you checkout the project and run

npm install
npm test

Then you get the following output

17:53 $ npm test

> nyc-babel-mocha-sourcemaps@1.0.0 test /Users/pghalliday/projects/github/pghalliday/nyc-babel-mocha-sourcemaps
> nyc mocha



  test
    1) should pass


  0 passing (15ms)
  1 failing

  1) test should pass:
     Error: what line number?
      at exports.default (src/index.js:1:1185)
      at Context.<anonymous> (test/src/index.js:8:5)



ERROR: Coverage for lines (50%) does not meet global threshold (100%)
ERROR: Coverage for statements (50%) does not meet global threshold (100%)
----------|----------|----------|----------|----------|----------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
----------|----------|----------|----------|----------|----------------|
All files |       50 |      100 |      100 |       50 |                |
 index.js |       50 |      100 |      100 |       50 |              3 |
----------|----------|----------|----------|----------|----------------|
npm ERR! Test failed.  See above for more details.

Note that it reports the error as being thrown from src/index.js:1:1185 even though the source file clearly throws on line 2

export default function() {
  throw new Error('what line number?');
  return 'hello world';
};

I have installed source-map-support and set nyc to have produce-source-map and babel to have "sourceMaps": "inline" and mocha to --require source-map-support/register (i tried moving that require to nyc too)

Am I missing something or does this just not work. Thanks in advance

[pghalliday]

I did notice this in the sourceMaps documentation for babel

If truthy, adds a map property to returned output. If set to "inline", a comment with a sourceMappingURL directive is added to the bottom of the returned code. If set to "both" then a map property is returned as well as a source map comment appended. This does not emit sourcemap files by itself! To have sourcemaps emitted using the CLI, you must pass it the --source-maps option.

I wasn't sure what to make of that as I'm not using the CLI here. I'm requiring babel-core/register in my .nycrc

[pghalliday]

Ok, it seems to work when I use babel-plugin-istanbul and babel-register, but then i don't need the rest of the source map configuration. I shall continue with that configuration.

I have pushed this working configuration to https://github.com/pghalliday/nyc-babel-mocha-sourcemaps/tree/babel-plugin-istanbul

[bcoe]

@pghalliday was going to recommend using babel-plugin-istanbul as well, as it works better for various edge-cases around transpilation.

Having said this, using source-map-support should also work: https://github.com/istanbuljs/nyc/blob/7708235b78f897348b17eaeb9fe0468e3350ae67/README.md#accurate-stack-traces-using-source-maps, @kpdecker I was trying to configure nyc-babel-mocha-sourcemaps to use source-map-support but not having any luck -- perhaps you could take a stab?

[JaKXz]

@pghalliday forgive me if I'm wrong, but it sounds like your issue has been resolved? Motion to close this issue? :)

[pghalliday]

@JaKXz only in the sense that I worked around it by doing something else. As such I don't know if the original issue has been resolved.

Also the workaround has some unpleasant side effects resulting in fragmentation of configuration (eg. excluding and including files for coverage in the babel configuration instead of the nyc configuration)

[JaKXz]

In your babel-plugin-istanbul branch you have the correct setup that's documented for ES2015+ support so I'd say that it's not a workaround but just correct now.

WRT to fragmenting the configuration: that's a valid point, but I think of it as a separation of concerns actually. When instrumenting ES2015+ code the instrumentation itself is handed off to the babel plugin so that nyc becomes a glorified reporter. This makes sense to me since babel is going through all your code anyway, so in the test env it makes sense that the coverage is calculated as it does that.

Hope that helps. Let me know if anything I said is not resonating.

[pghalliday]

Ok, but the issue is that source maps don't work without the plugin when they should.

From the documentation it states that the plugin provides "better" support, specifically for better code highlighting in reports. AFAIK source maps are intended to work without the plugin, so the issue remains.

[bcoe]

@pghalliday we definitely seem to have some issues with sourcemaps; would love help debugging this -- maybe we can start getting some unit tests around some of the failing behavior over time.

Let's leave this ticket open for motivation.

[paldepind]

I'm using a setup equivalent to what's described here.

It used to work perfectly but as of version 10.3 it doesn't.

[bcoe]

@paldepind when you have a second, please open a bug with a link to a specific repo having the issue.

[paldepind]

@bcoe No problem. It's an open source library. You can find it right here. I've just downgraded from ^10.3.0 to 10.2.x which made source maps work again.

Please ask if there's anything else I can assist with.

[bcoe]

@paldepind I wonder if you were on 10.3.0 which had a couple bugs fixed in 10.3.2? I've updated your configuration slightly, and switched to nyc@10.3.2 seems to work like a charm:

https://gist.github.com/bcoe/0844b24c53cb81de703c091490034a23

let me know if I'm missing something.

[paldepind]

@bcoe

I wonder if you were on 10.3.0 which had a couple bugs fixed in 10.3.2?

That is probably it. With 10.3.2 both my existing configuration and the one, you posted works.

Thank you for the help!

[sompylasar]

#619 (comment)

[bcoe]

closing in favor of #619.