Esbuild: Version 0.6.5 breaks source maps

Created on 25 Jul 2020  路  13Comments  路  Source: evanw/esbuild

Source maps are broken after updating to 0.6.5: in DevTools, the line correspondence is wrong, it suddenly started showing typescript source files of third-party libraries instead of their imported compiled versions, and folding is all over the place.

Not sure how to minimally reproduce the bug, there are quite a few dependencies, but here is the command I use:
esbuild --bundle --target=es2020 --sourcemap --outfile=dist/js/bundle.js src/index.js

Among the more complicated dependencies I have material-web-components, till now their compiled versions were shown in source maps, in 0.6.5 esbuild shows their typescript sources.

EDIT: Same goes for 0.6.6

All 13 comments

This change was intentional. See the release notes for 0.6.5 and #211, the relevant issue. Source maps in input files are now respected.

I'm guessing the main issue with the current approach is that the output source map is using the paths from the input source map verbatim, so the original files are shown at the top level in developer tools. Is that what you mean by "folding is all over the place"? I should probably change them to be parented under the corresponding node_modules/@material/... folder containing the compiled file that references the source map.

This change was intentional. See the release notes for 0.6.5 and #211, the relevant issue. Source maps in input files are now respected.

Is there a way to opt out? Seems to me like introducing extra point of failure, what if the existing source maps are wrong? Currently, all my maps are wrong, and I suspect something went wrong in these imported source maps and threw off esbuild.

Is that what you mean by "folding is all over the place"? I should probably change them to be parented under the corresponding node_modules/@material/... folder containing the compiled file that references the source map.

Yes, indeed, that's what I meant by this strange folding.

The latest release changes the original source map paths to be relative to the directory containing the source map. That should fix issues with the files ending up mounted at the root in developer tools.

Currently, all my maps are wrong

Can you say what is wrong about them? Is it possible to give me a way to reproduce the problem? I tried making a simple bundle that uses the library you pointed to and all of the source maps appear to be correct to me. Ideally I'd like to fix whatever's wrong instead of masking the problem.

Can you say what is wrong about them? Is it possible to give me a way to reproduce the problem? I tried making a simple bundle that uses the library you pointed to and all of the source maps appear to be correct to me. Ideally I'd like to fix whatever's wrong instead of masking the problem.

I have updated to 0.6.7, files are mounted correctly now, and source maps of third-party libraries seem to work correctly, including those using preexisting source maps like mwc components. However, maps of my own files seem to point to different files, e.g. if I set a breakpoint on line 55 of 's-dashboard.js' in reality it breaks on the same line 55 but in different file, say, 's-invite.js', ~I cannot figure out the correlation between the two for now. Is it possible that esbuild is mixing up files here for some reason?~

EDIT: Might be off-by-one error: 's-invite.js' code follows 's-dashboard.js' code in the bundle, the same goes for other files, setting a breakpoint on a line in one file results in breaking on the same line but in a file next to it in the bundle. And it only affects files in the same folder as my entry point, src/index.js, i.e. src.

I have tried importing the module you mentioned into several different code bases but I cannot reproduce an off-by-one error in the generated source maps. Are you able to provide a code base I could use to reproduce the issue? Otherwise I will unfortunately be unable to fix it.

I also have problems with sourcemaps. Often, setting a breakpoint within the bundled js file redirects me to the last line of a completely unrelated ts, or tsx file. Most of the lines are completely "disabled" in some files, meaning I can't set breakpoints to them, but even if I could, it would probably get to a wrong place, see attached screenshot:
Capture

In my other projects (using esbuild), sourcemaps seem to be completely fine, though. I'm trying to figure out what causes these strange problems.

EDIT: I investigated a little bit, and found out that the sourcemaps are completely fine if I use older versions of esbuild. I figured out that 0.5.26 is the latest version where it's okay, see this:
5 26

So something must have happened to sourcemaps between 0.5.26 and 0.6.0. The strange thing is that I can't see anything in the changelog at the 0.6.0 section related to sourcemaps. Do you have an idea @evanw what it might be? Again: it's not affecting all my projects, so it's kind of mysterious.

@soadzoor Are you able to provide sample code that reproduces the issue? I should be able to fix this if I can reproduce it.

@evanw I'm afraid I'm not allowed to share it on public platforms, but I can share it with you privately if you provide an email address (and you promise you won't share it either.. 馃槃 ) You can also contact me at soadzoor at gmail, if you don't want to share your email here.

@evanw I've finally manged to reproduce it here: https://github.com/zandaqo/esbuild_sourcemapping
If you open index.html in browser, go to sources, and open sources for ./src/a.js, you'll notice that you can only set breakpoints on lines 1, 3, 5 (the lines available in b.js), if you do set a breakpoint and reload it will look like it breaks at those lines, but in reality break on the same line in b.js. If you check the bundle, the code for b.js immediately follows the code for a.js.

@zandaqo Thank you so much for providing a way to reproduce the issue. I believe I have fixed the problem, and the fix should be in version 0.6.11. It was indeed an off-by-one error. Can you confirm that this version fixes your issue?

@soadzoor Thanks for offering to share your code privately. I'm hoping that this release fixes your issue too and that I don't need to take you up on your offer. Can you confirm as well?

@evanw I can confirm: sourcemap is perfect with 0.6.11 in my case as well! Thank you very much!

@evanw Yes, the off-by-one is gone, my own sources are correctly mapped by 0.6.11, thank you!

On a possible related issue, sources are missing for some dependencies in my example, e.g. sources at dist/js/node_modules/@material/animation/util.ts, .../@material/base/..., etc. from what I can gather, the ts dependencies that are not explicitly imported (dependencies of my dependencies so to speak) are missing with a ERR_FILE_NOT_FOUND error.

It looks like this is because their source maps are incomplete. They are missing the sourcesContent field containing the original source code. Seems like a mistake on their end because there's an open issue about it: https://github.com/material-components/material-components-web/issues/5638. It should be easy to fix by adding "inlineSources": true to their tsconfig.json file.

This would only be a problem if you need to debug those files, and I'm guessing this issue hasn't been addressed yet because they aren't expecting people to need to debug those files. For what it's worth Parcel does the same thing as esbuild here: https://github.com/parcel-bundler/parcel/issues/2185.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ojanvafai picture ojanvafai  路  3Comments

elektronik2k5 picture elektronik2k5  路  3Comments

evanplaice picture evanplaice  路  3Comments

egoist picture egoist  路  3Comments

aelbore picture aelbore  路  3Comments