What is the trick to Source Maps

[resistorsoftware]

Using the build command I get a sourcemap in app/assets/builds

  "build": "esbuild app/javascript/*.* --bundle --sourcemap --outdir=app/assets/builds",

Specifically, I get a file application.js.map

So great!

But in my browser, Firefox, it always complains as it is looking for the long bundled awkward name for things, and it never finds that. So I get an error all the time in my console looking something like this:

Source Map URL: application.js-e84a27730b114085524199296fb80196530bd624085878c84ebd17a1a0eeead3.map

Is there a way to clean this up? It seems like there is a missing step somewhere, and I am not smart enough to figure it out. I can delete the --sourcemap directive and remove the application.js.map from my builds completely, and I care not.. but I am sure for debugging purposes, that might be a dumb idea.

[evanw]

It's unclear what's going on. There is no code in esbuild that generates URLs which look like application.js-e84a27730b114085524199296fb80196530bd624085878c84ebd17a1a0eeead3.map, so this isn't esbuild's doing. The files generated by esbuild should end in something like //# sourceMappingURL=application.js.map for a file called application.js. If the browser is seeing application.js.map and loading application.js-e84a27730b114085524199296fb80196530bd624085878c84ebd17a1a0eeead3.map instead then something is wrong with your browser.

You could maybe be running into trouble if you're running another tool (or browser extension or web server?) that edits the generated files after esbuild but then the problem is with that other tool. If so, one thing you could try is --sourcemap=inline to avoid having a separate source map file which hopefully would avoid whatever bug is in that other tool.

[resistorsoftware]

Great explanation. I guess I have to continue in my search for why Firefox is asking for a file that is clearly decorated with some extraneous information.

[hleb-rubanau]

As this link pops up second in google for "esbuild + sourcemappingURL" search, let me add my 2 cents.

Given the directory structure (app/assets/builds) it's reasonable to assume that you're building assets in context of the Rails project.

In Rails, there's a widely used gem sprockets-rails, responsible for assets precompilation. Sprockets-based precompilation consists of several steps, one of which is esbuild (or other builder) invocation, and digesting is another, independent step, applied afterwards.

Therefore, esbuild output (app/assets/builds) becomes an input for sprockets, which copy digested versions into public/assets (also applying some post-processing to replace plain URLs with digested versions). And public/assets is your final version of assets served to clients (app/assets/builds is not).

The fact that in your case sourcemapping URL (effectively, a comment at the bottom of compiled JS file) points to a plain (not "digested") url of the sourcemap file, has nothing to do with esbuild itself, its either sprockets bug or sprockets misconfiguration.

[pricklywiggles]

Old thread but I figure this might help someone. @hleb-rubanau is correct about this, most likely your bundle files are being fingerprinted by sprockets. Your best bet here is to handle the fingerprinting of those files directly on esbuild.

You can have esbuild generate a hash with

assetNames: "[dir]/[name]-[hash]"

You'll then see that your files are being double fingerprinted. There's a secret incantation to prevent sprockets (or propshaft) from doing this, just end your generated names with ".digested"

assetNames: "[dir]/[name]-[hash].digested"

Note that if you are code splitting, you'll wanna do the same with chunkNames