You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be handy to be able to access a sourcemap that's generated and stored inline in a .transform'd file from the TransformResult as well. Right now, if sourcemap: "inline" is set, there's no sourcemap in the returned TransformResult. If it's not a major performance hit, it'd be awesome to just have access to the map when using sourcemaps: "inline" by default, but if not, a "both" option a la babel might make sense too.
My use case is this: when using esbuild in a development setting, sometimes there are multiple downstream consumers, each expecting to find sourcemaps in their own strange way. In my case, I'm using esbuild-jest to transform TypeScript files for Jest, and then using VSCode to edit said sourcefiles. VSCode accesses sourcemaps on disk or via the inline data: URLs, so if I want to debug my code with breakpoints from the editor, I want to pass sourcemaps: "inline" to give VSCode the sourcemap. But, Jest also consumes sourcemaps in order to provide nice rich error messages that show the source around an assertion error, and it uses the sourcemap to do that. Its API expects to be passed the sourcemap and the code from anything transforming code (like esbuild-jest), so I want to pass sourcemaps: true to esbuild to get a sourcemap to hand to Jest. I can teach one of the things in the chain of tools to find the sourcemap in one place and move it to the other, but it'd be handy if esbuild produced it in both places since it will be the most performant thing at doing that.
The text was updated successfully, but these errors were encountered:
It'd be handy to be able to access a sourcemap that's generated and stored inline in a
.transform
'd file from theTransformResult
as well. Right now, ifsourcemap: "inline"
is set, there's no sourcemap in the returnedTransformResult
. If it's not a major performance hit, it'd be awesome to just have access to the map when usingsourcemaps: "inline"
by default, but if not, a"both"
option a la babel might make sense too.My use case is this: when using esbuild in a development setting, sometimes there are multiple downstream consumers, each expecting to find sourcemaps in their own strange way. In my case, I'm using
esbuild-jest
to transform TypeScript files for Jest, and then using VSCode to edit said sourcefiles. VSCode accesses sourcemaps on disk or via the inlinedata:
URLs, so if I want to debug my code with breakpoints from the editor, I want to passsourcemaps: "inline"
to give VSCode the sourcemap. But, Jest also consumes sourcemaps in order to provide nice rich error messages that show the source around an assertion error, and it uses the sourcemap to do that. Its API expects to be passed the sourcemap and the code from anything transforming code (likeesbuild-jest
), so I want to passsourcemaps: true
toesbuild
to get a sourcemap to hand to Jest. I can teach one of the things in the chain of tools to find the sourcemap in one place and move it to the other, but it'd be handy if esbuild produced it in both places since it will be the most performant thing at doing that.The text was updated successfully, but these errors were encountered: