Inlining source content doesn't always include them.

[ianstormtaylor]

If a dependency is compiled with TypeScript and forgets to set inlineSources: true (which seems like the default?), then it will result in a null entry in the source map's sourcesContent array.

If you're bundling your output into a single file and serving that single file with its sourcemap inline (so that it's all contained in one place), then Chrome Devtools will fail when you try to step in to the source of that dependency with Could not load content for … because of the null value in the sources content array.

I understand situations where you'd want to have all source content omitted with the sourcesContent: false option to save space. But when sourcesContent: true is set, is there ever a case where you'd want null entries? Wouldn't it be better if esbuild inlined the sources content itself if it was missing in the upstream package? (Or potentially as a separate bundleSources setting?)

I might be missing something since source maps are a little cryptic. If so I apologize.

But my use case was essentially hoping to bundle everything into a single file, with all source information included inline, so that no external requests are needed to provide full debugging abilities.

[ianstormtaylor]

Also, just for clarity, this isn't a TypeScript-specific problem. Any dependency that is bundled with its own source map that omits the sourcesContent has the same result.

For example, the simplex-noise package references its source map which doesn't have sourcesContent. And this will show up as null after bundling too.

[evanw]

Ah, I see. I believe this is a request for esbuild to try to find the original source code on the file system and include it if it's present. That's not something that esbuild currently does but I think it makes sense for esbuild to do this. I'll look into it.

is there ever a case where you'd want null entries?

Yes, I think so. Consider a package with node_modules/pkg/index.js and node_modules/pkg/index.js.map. If the original source in the source map is index.ts but there is no index.ts file, then I think there are only the following options:

1. Put null in the sourcesContent for index.ts. This means that stack traces will still show up as index.ts with the correct line and column numbers, but the code won't be available. This seems desirable in situations where you are only logging lightweight stack traces and don't want to pay for the cost of downloading/storing all of the source code, which can be quite large.

2. Ignore the input source map because the original source code is missing. This means that stack traces will show up as index.js with line and column numbers for index.js. So the original source code will always be available but it may be the transpiled code instead of the original. This doesn't seem great as it is disregarding the source mapping instructions present in the file.

A third option would be to put index.js in the sourcesContent for index.ts instead of null. However, I don't consider that to be a valid option. While it means the original source code is never null, the line and column numbers could be completely unrelated, which would be very confusing.

Right now esbuild does option 1 here, which seemed the most correct to me.

[ianstormtaylor]

Amazing, thank you @evanw! Totally makes sense about needing null when the original source isn’t in the filesystem at all.