-
Notifications
You must be signed in to change notification settings - Fork 782
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
Support source maps (Browserify) #590
Comments
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/ |
That would certainly be interesting. It's also something I've been requesting for TraceKit and StackTrace.js. |
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). |
+1, I would also love source maps in tracebacks, which are generated by traceur in my case. |
👍 I'm transitioning WYMeditor to CommonJS with Browserify and I'm seeing this dreadfully unhelpful thing. |
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. |
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 Verified with Webpack in PhantomJS + Chrome, but should work with Browserify (and anything else that includes a sourcemap). |
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. |
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.
The text was updated successfully, but these errors were encountered: