Sourcemaps ignored by apps bundled with Bun.build and sourcemap: 'external'

[mangs]

What version of Bun is running?

1.1.9+bb13798d9

What platform is your computer?

Darwin 23.4.0 arm64 arm

What steps can reproduce the bug?

1. Bundle app using Bun.build and the following build configuration:

{
  define: {},
  entrypoints: ['./src/index.mts'],
  external: [],
  format: 'esm',
  loader: {},
  minify: true,
  naming: {
    chunk: '[name].[hash].mjs',
    entry: '[name].mjs',
  },
  outdir: './dist',
  plugins: [],
  publicPath: '',
  root: '.',
  sourcemap: 'external',
  splitting: true,
  target: 'bun',
}

2. Start app using the bundled resources
3. Make the app throw an error
4. Get a minified stack trace instead of a link back to the original source code

What is the expected behavior?

If I run the same code with a manually thrown error but point to the typescript files directly instead of using pre-bundled ones, I get the following stack trace:

30 |
31 | // Lambda Handler
32 | async function lambdaHandler(request: Request): Promise<Response> {
33 |   customizeRollbarPayload(request);
34 |
35 |   throw new Error('boooo');
             ^
error: boooo
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/src/index.mts:35:9
      at lambdaHandler (/Users/egoldstein/code/babbel/get.apigateway.lambda/src/index.mts:32:30)
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:201:20
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:190:48
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/timeUtils.mts:100:29
      at measureElapsedTime (/Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/timeUtils.mts:98:38)
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:190:17
      at fetch (/Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:186

The bundled app stack trace should look the same.

What do you see instead?

1 | // @bun
2 | import{d as j} from"./index.8b306d478767a477.mjs";import"./index.04c119a3beb16a35.mjs";import{m as W,q as F,r as K,t as _} from"./index.cc647d1f6d9b8e22.mjs";var{dns:x}=globalThis.Bun;var{Glob:w}=globalThis.Bun;var A=["ALL","DELETE","GET","HEAD","OPTIONS","PATCH","POST","PUT"];class B{constructor(Q=!0){this.#Y=[],this.#Z=Q}#Y;#Z;async handleRequest(Q){const Y=performance.now(),{method:Z}=Q,{pathname:$}=new URL(Q.url);for(let[X,[O,z]]of this.#Y){if(X!=="ALL"&&Z!==X)continue;if(new w(O).match($)){if(typeof z==="function"){if(this.#Z)Q.headers.append(...j("routeSync",Y));return z(Q)}const[D]=Object.entries(z);if(!D)throw new TypeError("No lazy-loaded configuration option provided");const[G,k]=D,C=(await k())[G];if(typeof C==="function"){if(this.#Z)Q.headers.append(...j("routeAsync",Y));return C(Q)}throw new TypeError(`Lazy-loaded route handler target "${G}" was not a function`)}}throw new Error("No routes matched!")}#Q(Q,Y,Z){if(!A.includes(Z))throw new TypeError(`"${Z}" is not a valid HTTP method`);return this. | ... truncated

error: boooo
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/dist/index.mjs:2:7221
      at f (/Users/egoldstein/code/babbel/get.apigateway.lambda/dist/index.mjs:2:7512)
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:201:20
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:190:48
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/timeUtils.mts:100:29
      at measureElapsedTime (/Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/timeUtils.mts:98:38)
      at /Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:190:17
      at fetch (/Users/egoldstein/code/babbel/get.apigateway.lambda/node_modules/@mangs/bun-utils/src/networkUtils.mts:186

Additional information

I've been working through this with @paperdave and we've tracked this down to potentially being caused by a null byte being inserted into .map file(s). Could be more than that, but that's where we've gotten so far.

I used the esbuild sourcemap visualizer to figure that out. Thanks Dave for the suggestion.

The visualizer gives the following error when trying to examine the entrypoint code and its sourcemap:

The imported source map contains invalid JSON data: JSON.parse: bad control character in string literal at line 11 column 28 of the JSON data

The null byte at line 11 column 28 from the source map file looks like this in VSCode:

[Jarred-Sumner]

does the output file have a source map url comment? i wonder if we are using that

[mangs]

There's a comment at the end of the minified JS. For example, the contents of the entrypoint file after bundling:

// @bun
<code_here>

//# debugId=109EB3EE161376B264756e2164756e21

wish I could share the code

[paperdave]

the solution for this issue should be to print warn when sourcemap loading fails. and then the second issue #11279 will be about actually fixing the invalid sourcemaps.

[paperdave]

forgot to close when i added the warning. this now prints a warning when a sourcemap fails to load but was tried.