Support source maps (Browserify)

[vahdani]

When using a build tool like Browserify, it's required to build a bundle even on development. In this environment QUnit will show the line numbers according to the build file which is confusing.
It would be great if QUnit could parse the related source map and reference real source files when an error occurs.

[jzaefferer]

I've never worked with source maps, so I can't really tell if that's realistic and how much effort it would require. This project would likely be a good starting point for an experiment: https://github.com/mozilla/source-map/

[JamesMGreene]

That would certainly be interesting. It's also something I've been requesting for TraceKit and StackTrace.js.

[leobalter]

Did some cross reference so each project can help other if we or them get something.

As we are going to work on the new reporter interface, it's easier to see this as an extension. I'm expecting some extra external dependencies and hard to cross browser support (including ie6).

[simonzack]

+1, I would also love source maps in tracebacks, which are generated by traceur in my case.

[mightyiam]

👍

I'm transitioning WYMeditor to CommonJS with Browserify and I'm seeing this dreadfully unhelpful thing.

[jzaefferer]

Once a library like TraceKit supports this, we can look into adopting it. If you want to help, look into integration of TraceKit into QUnit. Otherwise this will probably stay open for another year or two.

[DrewML]

For anyone still looking for this support, you can essentially hack it yourself using the browser build of node-source-map-support. Note that it will only work in browsers whose Error objects include a stack property.

Verified with Webpack in PhantomJS + Chrome, but should work with Browserify (and anything else that includes a sourcemap).

[Krinkle]

I've confirmed that Node's built-in support for source maps (Node 14+) works fine with QUnit. This is now validated through an integration test in our CI, and documented at https://qunitjs.com/cli/#nodejs-cli-options.

For the browser, I would recommend using the browser's own dev tools. You can use these by ticking the "No try-catch" checkbox in the QUnit browser interface. This will allow you to get regular dev tooling going based on uncaught exceptions.

I filed #1748 to write this down on the site as well.