Skip to content

Get rid of webpack's prefix on TypeError #2257

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

Closed
RohovDmytro opened this issue May 19, 2017 · 7 comments
Closed

Get rid of webpack's prefix on TypeError #2257

RohovDmytro opened this issue May 19, 2017 · 7 comments

Comments

@RohovDmytro
Copy link

RohovDmytro commented May 19, 2017

Image

The source code is prettified by sourcemaps, but the error title does not fully correspond with it.

@gaearon
Copy link
Contributor

gaearon commented May 19, 2017

Yea, it's not super nice. But it's important to have it match the compiled code because if the error is really weird, you'll want to switch to "view compiled" and see if it's Babel messing things up or not. In this case it's very valuable to have the error correspond exactly to the code that runs in the browser.

I think the right solution here is to lobby Webpack to change that prefix to something shorter 😄 .

@RohovDmytro
Copy link
Author

@gaearon can we apply sourcemaps to make error more readable? We can show it's real content only if user is clicking on «View compiled»

It's not super important. It's just that this overlay is super nice feature 😈

@gaearon
Copy link
Contributor

gaearon commented May 19, 2017

I'm not sure if there's a way to map variables back, but let me know if you find it :-)

@Timer
Copy link
Contributor

Timer commented May 19, 2017

I'm pretty sure the variable maps are explicitly excluded/stripped by webpack's cheap maps.
See webpack/source-list-map#2

@gaearon
Copy link
Contributor

gaearon commented May 19, 2017

Ah. It's probably not intentional though? They're excluded because transform couldn't handle them, but not because they're necessarily expensive (I don't know, just a guess). If that's true maybe we can contribute to pass them through.

@gaearon
Copy link
Contributor

gaearon commented Jan 8, 2018

I feel like we should preserve the original text for more complex scenarios. Obfuscating it could actually make debugging more confusing.

I suggest you to file this with webpack and ask them to use a shorter obscure sequence. For example __webpack_import_0__lodash_default.

@gaearon gaearon closed this as completed Jan 8, 2018
@gaearon
Copy link
Contributor

gaearon commented Jan 8, 2018

OK, I filed webpack/webpack#6266

@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants