esbuild generates different sourcemaps from ts-node in coverage reports

[shigma]

I know this may be a complex issue.

• test framework: mocha
• coverage tools: c8 (html reporter)
• source file: https://github.com/koishijs/koishi/blob/next/packages/koishi-core/src/context.ts
• test spec: https://github.com/koishijs/koishi/blob/next/packages/koishi-core/tests/context.spec.ts

ts-node

I used ts-node/register/transpile-only.

esbuild

I used a register script written by myself: https://github.com/koishijs/koishi/blob/next/build/register.ts

[evanw]

It's true that esbuild and TypeScript don't generate identical source maps. That's not a bug though, that's just because they do slightly different things. For example, esbuild doesn't put source mappings at the end of identifiers, only at the start, because they aren't relevant for stack traces and removing them makes the generated source map smaller.

You have just said they are different but you haven't said why that matters to you. For example, why not log a bug with ts-node saying their source maps are different than esbuild? Is there something specific about esbuild's source map output that is incorrect?

I have a source map debugging tool here: http://evanw.github.io/source-map-visualization/. If you can point to an incorrect source mapping in esbuild, then that's something I can fix.

[shigma]

Thanks for your quick response. The source maps that esbuild generates are working well enough for my debugging. I'm not suggesting esbuild's sourcemap is buggy or something. What I intended to inform is esbuild+c8 generated an obviously incorrent coverage report like this:

I'm not familiar to coverage reports and I don't know if the incorrectness was caused by esbuild. If not, I will close this issue.

Also a lot thanks for your debugging tool. I will investigate on it with my example.

[evanw]

Ah, I see. For debugging you only need mappings at the start of 47 and the start of segment, so esbuild only generates mappings there. I have never seen a JavaScript VM throw an error starting at a ? because there is no executable code there.

I guess the problem is that whatever program you're using to generate that visualization is looking up into the source map at the ? instead of at the location of the code in each branch. One way to fix that could be to fix the visualization library to look up into the source map where the code is located. Another way to fix this could be for esbuild to generate a source mapping at the ? although that isn't super straightforward because there is currently no AST representation of that location since there is no code located there.

[evanw]

I just checked the source maps of another popular JavaScript transformation toolchain (acorn for parsing and astring for code generation) and those source maps also don't have a mapping before the ?, as I expected. That confirms to me that the problem here seems to be that this visualization library is looking up the source maps in the wrong place instead of that esbuild is generating incorrect source maps.

This happens to work with the TypeScript compiler because TypeScript happens to preserve all tokens in their AST. I'm not totally sure why they do this but I believe this is somewhat unusual. Most JavaScript tools follow the ESTree AST specification in which ConditionalExpression does not encode the positions of every token.

[evanw]

One thing I can do is generate a source mapping at the start of blocks (so before the { token of the block). This seems reasonable to me as there is actually an AST node there, although it will still never actually be referenced by a thrown error. That's what the commit above does.

[evanw]

Closing for the reason described above. I don't believe esbuild is doing anything incorrect or unusual here, and it seems like the issue is with the visualization tool you're using instead.