-
-
Notifications
You must be signed in to change notification settings - Fork 27k
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
Comments
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 😄 . |
@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 😈 |
I'm not sure if there's a way to map variables back, but let me know if you find it :-) |
I'm pretty sure the variable maps are explicitly excluded/stripped by webpack's cheap maps. |
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. |
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 |
OK, I filed webpack/webpack#6266 |
Uh oh!
There was an error while loading. Please reload this page.
The source code is prettified by sourcemaps, but the error title does not fully correspond with it.
The text was updated successfully, but these errors were encountered: