-
Notifications
You must be signed in to change notification settings - Fork 38
Broken sourcemaps #28
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
See rsms/estrella#28 . We were working around this by passing `sourcemap: "inline"` but doing that is very bad (it makes the bundle much much larger). Instead, use a forked version which removes Estrella's broken attempt at transforming sourcemaps.
I've dug into it and it seems esbuild now generates "good" sourcemaps. I'm removing the patching code with one exception: When you generate a sourcemap but no output javascript, the paths of the sources themselves need to be patched no matter what. (there's a test for this at With the changes I'm about to land, you can now ask for sourcesContent by providing the (esbuild-inherited) option sourcesContent like so: build({
sourcemap: true, // or inline or filename
sourcesContent: true,
}) This will cause esbuild to include |
Shipped with release 1.4.0 |
After each build,
patchSourceMap
modifies the source-maps esbuild emitted, deleting thesourcesContent
field and settingsourceRoot
to a relative path from the output directory to the working directory. In practice, if the output file is a webap, this breaks source mapping; the relative path doesn't point anywhere sensible when it's treated as a UR. Commenting out the call topatchSourceMap
fixes it, as does usingsourcemap:"inline"
(but the latter drastically increases the size of the output javascript bundle).The text was updated successfully, but these errors were encountered: