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

Babel sourcemaps rejected as invalid #39

Open
dwickern opened this issue Sep 17, 2017 · 6 comments
Open

Babel sourcemaps rejected as invalid #39

dwickern opened this issue Sep 17, 2017 · 6 comments

Comments

@dwickern
Copy link

When babel sourcemaps are enabled from ember-cli-babel, you still won't have es6 sourcemaps in the ember dist.

The sourcemaps are being rejected by sourcemap-validator. I wrote up the details over at ben-ng/sourcemap-validator#8

It seems the babel generated sourcemaps are technically invalid, but they still work fine in the browser, and other frameworks using babel don't seem to have this issue. Maybe consider getting rid of the sourcemap validation?

/cc @rwjblue @stefanpenner

@rwjblue
Copy link
Collaborator

rwjblue commented Sep 17, 2017

Hehe, we should likely try to fix the babel source maps so they are correct and valid. A little while back @chadhietala created babel/babel#6008 on the subject...

@stefanpenner
Copy link
Collaborator

It seems the babel generated sourcemaps are technically invalid, but they still work fine in the browser,

They don't actually work though. And can cause other downstream maps issues.

@gdborton
Copy link
Contributor

Would it be possible to add an option to skip validation? Until babel/transformation tooling is fixed? Using poor sourcemaps are better than opting to use no sourcemaps.

@stefanpenner
Copy link
Collaborator

stefanpenner commented Mar 2, 2018

Using poor sourcemaps are better than opting to use no sourcemaps.

Are you sure about that? Having source-maps where the debugger breakpoints don't work, variables are totally un-inspectable.. etc. Also remember, when this occurs downstream source-maps also become broken. So source-maps that are actually valid, become affected.

I personally don't think this is acceptable, and don't look forward to the inevitable bug reports/emo people will have when they force this on, and end up with random other failures.

@gdborton
Copy link
Contributor

@stefanpenner So I've been giving this a bit more thought, and there are reasons other than just babel's source maps for providing this option.

In my case transforms are applied to individual files, then cached, then in a later process transpiled code and maps are used to generate a bundle. For optimal performance it would make the most sense to validator the individual source maps just before caching and mark them with a flag. In this case we wouldn't want to rerun the validator.

@stefanpenner
Copy link
Collaborator

stefanpenner commented Mar 28, 2018

Caching the validator result seems like a good idea.

In theory, one could write an efficient source-map decoder that could validate as it encodes.. That is likely much more work, but likely also faster/better across the board.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants