`upload js` crashes with "open : no such file or directory" when .map has no same-name .js bundle

[kaisermann]

When running bugsnag-cli upload js .next/ on a Next.js Turbopack build, the CLI crashes with:

open : no such file or directory

The error is missing the filename, which made this very hard to debug on our Vercel production builds.

What's happening: Turbopack uses independent content hashes for .js bundles and their .js.map files. A bundle abc123.js contains //# sourceMappingURL=def456.js.map. The map file exists on disk, but there is no def456.js. This is intentional on Turbopack's side (vercel/next.js#85471).

The crash happens because resolveBundlePath strips .map to find the bundle. When the file doesn't exist, it returns an empty string with no error. That empty string reaches os.Open(""), which panics.

Suggestions:

1. When no bundle is found for a map file, skip it with a warning or return a clear error instead of crashing.
2. Would you consider reading //# sourceMappingURL= comments from .js files to discover the actual pairing? The Turbopack maintainers consider this the standard mechanism (their response). It would work regardless of how the bundler names its output files.

Minimal repro with build output included: https://github.com/kaisermann/turbopack-sourcemap-repro

[hannah-smartbear]

Hi @kaisermann,

Thanks for raising this.

It’s worth noting that BugSnag can map JavaScript events using one of two mechanisms:

• First, we look for maps uploaded to BugSnag that match the URL of the frame in the stack trace, and the app version of your event.
• If no match is found, we then look for a //# sourceMappingURL= comment in your Javascript file or a X-SourceMap header to see if we can scrape the source map from your server. Note, for this method to work, BugSnag needs to be able to publicly see this map.

As such, you can choose not to upload source maps if you wish to use the second mechanism.

Alternatively, if you still wish to upload your source maps via the bugsnag-cli, you can specify the bundle path explicitly using the --bundle flag, which is documented here.

Regarding the logging in this scenario, we will raise this internally.

Please do let us know if you continue to experience any issues or have any questions about this.

[kaisermann]

Hey @hannah-smartbear, thanks for the response!

Neither alternative works well for our use case, and I think this is worth explaining because it likely affects anyone using turbopack (or any bundler that doesn't use same-name pairing as mentioned in OP):

First option, scraping, won't work. We delete all .map files from the deployment before it goes live, as serving source maps publicly in production is a security concern (it exposes our source code). This is actually the primary reason we use the upload workflow: to give Bugsnag the maps without making them publicly accessible.

The --bundle alternative is per-file, not a fix for directory uploads. Yes, we could iterate over every JS/map pair ourselves and call bugsnag-cli upload js --bundle <file> --source-map <map> for each one. But bugsnag-cli upload js .next/ is the documented way to batch-upload from a directory, so I assume it should handle the correct pairing of .map to .js file.

Again, the issue is that its pairing logic assumes map files are named <bundle>.js.map, which is a bundler-specific convention, not a standard.

The standard mechanism for associating a bundle with its source map is the //# sourceMappingURL= comment in the JS file. This is what browsers use, what Turbopack emits, and what the sourcemap spec (https://sourcemaps.info/spec.html) defines.

The CLI already walks .js files during directory uploads, so reading these comments to discover the actual pairing would make it work correctly regardless of the bundler's naming conventions.

We currently work around this by renaming all .js.map files to match the <bundle>.js.map convention before uploading, and rewriting the sourceMappingURL comments to match. It works, but it's a non-trivial workaround for what should be handled by the CLI's directory walker.

Would the team consider supporting sourceMappingURL-based discovery as the primary pairing mechanism during directory uploads? It would fix this for turbopack and any other bundler that uses independent hashes.

[hannah-smartbear]

Hi @kaisermann,

Thanks for your feedback. We’ve passed this on to our engineers for their consideration, and we will let you know of any updates.