Skip to content
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

Find a way to preserve line numbers in error messages / stack traces #605

Closed
andreypopp opened this issue Sep 8, 2016 · 12 comments
Closed
Milestone

Comments

@andreypopp
Copy link
Contributor

Seeing incorrect line numbers in stack traces breaks workflow too much.

We could try to either use line preserving code transformations (does Babel support that?) or enable more advanced Webpack's devtool (cheap-module-eval-source-map).

@ForbesLindesay
Copy link
Contributor

I strongly believe that source maps is better than no source maps even in the current state. We should definitely file issues with upstream projects, but in the short term I'm not aware of any development teams that intentionally disable source maps in development.

@gaearon
Copy link
Contributor

gaearon commented Sep 8, 2016

I'm open to enabling them but not without somebody compiling a list of issues that need to be addressed in other projects for them to work seamlessly.

@ForbesLindesay
Copy link
Contributor

Isn't it just the need for a variable name map? i.e. currently dev-tools requires you to see the name of the variables after compilation rather than the name they had in the source code. 95% of the time those are the same thing anyway (unless you add a minifier), but it is still worth pushing to get fixed.

@andreypopp
Copy link
Contributor Author

95% of the time those are the same thing anyway (unless you add a minified)

I think imported names are mangled and this is not 5%.

@gaearon
Copy link
Contributor

gaearon commented Sep 8, 2016

Isn't it just the need for a variable name map?

Yeah, maybe. At least if cheap-module-source-map truly works well with breakpoints unlike some of its friends (IIRC, cheap-module-eval-source-map) that complete confuse debugger in Chrome.

Another thing to watch out for is hot reloading support. We don’t have it right now but I’d like to see us be ready to it in the future. I know sourcemap support for it was fixed for eval but not sure if they get updated for cheap-module-source-map, for example, and whether we need to file more Chrome bugs.

95% of the time those are the same thing anyway

I’m not sure this was my experience with destructuring (or some other common ES features) but worth double checking. Imports are confusing too, I wish there was a way around that while preserving ES modules semantics.

@gaearon gaearon added this to the 1.0.0 milestone Sep 8, 2016
@mpj
Copy link

mpj commented Oct 11, 2016

Not having source maps is definitely problematic. Chrome chrashes on my Macbook Pro if I try to do searches and add breakpoints in bundle.js.

@mpj
Copy link

mpj commented Oct 11, 2016

... and when it actually works, it's unintelligible garble due to the eval thingee.

@gaearon
Copy link
Contributor

gaearon commented Oct 11, 2016

@mpj

Can you put breakpoints in the modules instead?

@mpj
Copy link

mpj commented Oct 11, 2016

@gaearon I don't understand. In my installation ("react-scripts": "0.6.1"), everything is just one big bundle.js.

@mpj
Copy link

mpj commented Oct 11, 2016

@gaearon oh, I get what you mean now, I have to expand into the webpack:// thingee. That works!

@sodik82
Copy link

sodik82 commented Nov 9, 2016

does/will this issue cover also line numbers in test/jest stack traces?

@gaearon
Copy link
Contributor

gaearon commented Feb 11, 2017

We have sourcemaps now so probably not relevant anymore.

@gaearon gaearon closed this as completed Feb 11, 2017
@lock lock bot locked and limited conversation to collaborators Jan 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants