Source map support

[trusktr]

Inline and external source-map support is very much needed (f.e. when using preprocessors). Is there currently an official way to use source maps so that the line numbers of my errors (the very things that jest revolves around) are meaningful?

[theengineear]

Any way to do this yet? Following suggestions from:

http://marmelab.com/blog/2015/06/24/jest-in-practice.html
https://medium.com/@dwerthen/speeding-up-react-testing-with-jest-5a300c1918b7#.bot61cbba

I took out the "scriptPreprocessor" so that I could manually watch for changes using babel-cli. Is it possible to use inlined source maps from babel yet in jest?

[cpojer]

I'm going to assume that this should probably work with babel. I'm going to close this as babel has a retainLines option that we are using in babel-jest and at FB we are currently unlikely to use another compile-to-JS language that needs this feature. Is there a reason why you'd want source maps if you know the exact line number of when something is failing?

I also appreciate contributions to babel-jest (see the packages/ folder) that improve support here.

[kellerapps]

I'm using typescript & jest reports the JS line numbers. Is there a workaround? Thx!

[Jessidhia]

A feature to preserve line numbers in typescript was specifically rejected because they already produce source maps: microsoft/TypeScript#3142

[kripod]

@cpojer There is a reason for adding source map support: codecov.io doesn't support coverage reports for files not checked into source control. I tried using remap-istanbul, but it couldn't resolve the original source paths correctly.

[felipeochoa]

I was finally able to solve this issue. See felipeochoa/jest-sourcemaps for the details. (It's not pretty, but it works!)

[felipeochoa]

@cpojer I was poking around the refactoring you did in #3376 and #3388 and was excited to see that source maps are cleanly handled when coverage is enabled! Is the plan to allow saving source maps independently of whether coverage is enabled? It seems to me that simply removing the else clause in line 227 and the instrument && mapCoverage on line 241 would be enough to let transformer authors specify sourcemaps.

A current limitation of the jest-sourcemaps approach is that I can't cache source maps, so having this built-in with jest would be amazing!

[cpojer]

@felipeochoa I have no smart thoughts on this to be honest, so feel free to send a pull request with the changes and with tests and we'll see where can take it.

[GAumala]

So, jest's support for source maps is currently limited to coverage only? If I write a custom preprocessor that extracts inline source maps for TypeScript I get accurate code coverage on my .ts files, but whenever I throw an exception the lines in the stack trace are completely wrong.

[tkrotoff]

I've managed to use remap-istanbul with TypeScript, this should work with other transpilers. I could get Codecov and Code Climate to work with this.
Here the explanations: https://github.com/codecov/example-typescript/issues/7

Edit: why not use ts-jest? Because you cannot debug (e.g set breakpoints) your tests with it, see kulshekhar/ts-jest#118 (comment) ts-jest now fully works, including vscode breakpoints

---

Copy-paste for history:

What you need to change in your code for it to work: tkrotoff/react-form-with-constraints@b581782

• Configure TypeScript to generate the source maps by adding "sourceMap": true to your tsconfig.json
• Configure Jest so that it generates only coverage-final.json thanks to "coverageReporters": ["json"]. By default Jest generates everything including the HTML report (lcov-report) and lcov.info
• Then use remap-istanbul to rewrite coverage-final.json using the source maps
• And finally istanbul report to generate the right HTML report (lcov-report) and lcov.info from the correct coverage-final.json

This blog post: https://medium.com/@novemberborn/code-coverage-with-babel-istanbul-nyc-83b8c2f1093 allowed me to understand.

[sean-killeen]

@tkrotoff Thanks for your help, you definitely have moved me in the right direction but my istanbul coverage report still shows the incorrect umber of lines.

while the actual lines in the file are:

Any help would be greatly appreciated.

[tkrotoff]

@sean-killeen you should use ts-jest, no need for remap-istanbul:

ts-jest now fully works, including vscode breakpoints

[sean-killeen]

I actually started with ts-jest originally and have been getting an error with istanbul-lib-coverage when using it.

at CoverageMap.fileCoverageFor (node_modules/istanbul-lib-coverage/lib/coverage-map.js:96:15)
at Array.forEach ()

that is what spawned this process.

update:

getting the latest versions of jest and jest-cli have resolved the cli error, however, the initial issue still persists while using ts-jest

[SimenB]

Jest should fully support sourcemaps out of the box now, as long as they are either inline or the transformer returns it (meaning we don't look up external sourcemaps).

@sean-killeen could you provide a repro of your issue?

[sean-killeen]

@SimenB I think this is an open issue with React 16 and Node 8. I found this which I think is the same issue. What I am getting is coverage but with incorrect line numbers. Looks the the numbers are generated from the transpiled source code that isn't source-mapped.

[patrickhulce]

Is there a conversation somewhere about why jest does not support external source maps/are they considered in the future? Having just transitioned form mocha and with all that's baked in, I somewhat expected this :)

The workarounds to get support seem much heavier than other test runners (see #2205 (comment)).

[SimenB]

PR welcome! We support inline sourcemaps, should be possible to support external as well.

[chase-moskal]

greetings typescript friends

i've found two harmonious workflows for jest+typescript+vscode that have worked well for me regarding source maps

1. use ts-jest on your ts files
   i've found ts-jest to "just work" excellently,
   it will hot-compile your ts files right before each test run,
   sourcemapping works like a charm, great dev experience

2. use jest on your js files, plus tsc option --inlineSourceMap
   the sourcemapping starts working once inline source maps are used instead of external ones,
   using jest directly (instead of ts-jest) allows us to skip the compilation step and save a little time (in a build routine, compilation may already happen before the tests are run)

if you use inline source maps, try to only do so in a debug build that isn't published -- you probably wouldn't want to publish to npm the js files which contain the big fat inline sourcemaps, it'd be terrible if everyone did that

[dfroger]

Jest should fully support sourcemaps out of the box now, as long as they are either inline or the transformer returns it (meaning we don't look up external sourcemaps).

@SimenB How does Jest support sourcemaps? (I was expecting to see in babel-jest something like in felipeochoa/jest-sourcemaps, ie calling babel.transform with {sourceMap: true}, and passing these outputed sourcemaps to node-source-map-support).

Edit: I'm looking at script_transformer.js in jest-runtime, should be ok for me to understand how jest support sourcemaps.

[SimenB]

Did you answer your own question? We might want to document how to utilise sourcemaps in Jest, but I'm not sure where to put it. It works out of the box, but custom transforms have to support it explicitly (by returning code and map properties)

[agborkowski]

@chase-moskal youp 🍺 inline source map in tsconfig.json compiler options solve the problem !

// ...
"sourceMap": true,
"inlineSourceMap": true,

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.