null in sourcesContent is still null in the output even if --sources-content=true

[sapphi-red]

When the input file has a sourcemap has null in sourcesContent, the output sourcemap will include null in sourcesContent. This happens even if --sources-content=true is set.

Reproduction

Reproduction with esbuild.github.io/try

• entry.js: imports foo.js
• foo.js: a bundle built from foo.ts and bar.ts
• foo.js.map: a sourcemap of foo.js
• foo.ts: the source of foo.js
• bar.ts: the source of bar.js

If I remove sourcesContent from foo.js.map, null doesn't appear in sourcesContent field of entry.js.map.

[evanw]

Can you say why the sourcesContent field has a null in it? Is this a problem with a library you're using? If so, this may need to be fixed in that library instead.

I'm asking because a null entry is a deliberate exclusion of the source code for that file. For example, some people deliberately omit file contents from source maps to keep the size down and/or because the source maps are only used for file/line/column entries in stack traces. Your example setup could also be indicating that the contents of bar.ts (which has a null entry in the map) should explicitly be excluded because it's known that the contents on the file system are not currently the same as what was used to generate the source map. Or it could indicate that the author does not want that source file in the source map, perhaps because it contains sensitive information.

Having esbuild try to do something else here could cause esbuild to do something that's not correct. So what esbuild is doing here doesn't initially seem like a problem with esbuild to me.

[sapphi-red]

Thanks for the response.

Can you say why the sourcesContent field has a null in it? Is this a problem with a library you're using?

It's @timonwa/demo-ui-library. It seems to be a package for demo though.
The reason why this package has null in the sourcesContent is because "inlineSources": true is not set in tsconfig.json. So I guess it's a misconfiguration of the package.

That being said, I think it's a valid choice to publish a package with having null entry for the original files and having a non-null entry for the dependency files. For example, a package like below.

• package.json: files field includes ./src/* and ./foo.js and foo.js.map
• foo.js
• foo.js.map: { sources: ['./src/foo.ts', './node_modules/pkg/pkg.js'], sourcesContent: [null, 'console.log()'] }
• src/foo.ts

In this case, what should the user that wants to use this package do?

As far as I know the source map spec only says "“null” may be used if some original sources should be retrieved by name.".

FWIW webpack/source-map-loader includes the sourcesContent even if the input sourcesContent is null.
https://stackblitz.com/edit/node-3jyvsx?file=dist%2Fmain.js.map

---

The original issue is vitejs/vite#13391. In Vite we're relying on the sourcesContent field in a special way, so the original issue itself isn't much important for esbuild. I reported this issue without including that context because I thought it will make the description complicated and I thought this would also be an issue when directly using esbuild as a bundler for a website.

[evanw]

Thanks for the reference to the specification. I agree that the specification sounds like esbuild should be trying to find the original source file in this case, so I will add this to esbuild.

[sapphi-red]

Thanks!