Consume source maps from JavaScript files

[kitsonk]

Current Deno will remap stack traces on files that have been compiled by Deno, as Deno caches both the original file and the emitted map, and loads those from the cache. When consuming JavaScript with source maps from other sources (like already compiled code) Deno does not handle the source map and ignore source map pragma included in files.

Deno should support both external source maps and inline source maps when fetching modules and store any source maps in the cache to be used when remapping stack traces.

This will have the side-effect of supporting the generation of source maps for bundles generated by deno bundle.

One consideration is that source maps optionally can include the original sources. If they do, then when emitting an error, the original source line is available, but if they don't, we would not be able to log-out/resolve that original source line.

[71]

Several issues referring to inline source maps were closed as duplicates of this one, but this also applies to linked source maps:

function fail() {
  throw new Error("failed");
}

fail();

Build with esbuild:

$ esbuild repro.ts --minify --sourcemap=linked --outfile=repro.js

With Node and source-map-support:

$ node -r source-map-support/register repro.js
file:///repro.ts:2
  throw new Error("failed");
        ^
Error: failed
    at fail (file:///repro.ts:2:9)
    at file:///repro.ts:5:1
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

With Deno:

$ deno run repro.js
error: Uncaught Error: failed
"use strict";function fail(){throw new Error("failed")}fail();
                                   ^
    at fail (file:///repro.js:1:36)
    at file:///repro.js:1:56

[skovsboll]

I would love better source maps support. Useful for debugging unit tests.

[scarf005]

they would be really useful, currently go to source definition feature doesn't work in esm.sh due to deno being unable to handle source maps.

[bartlomieju]

This needs to be redesigned and implemented in deno_core.

The problem is that we have our own system of handling source maps and not using the built-in V8 APIs that Luca mentions here.

We currently have a SourceMapGetter trait that needs to implement a couple methods to retrieve a source map.

Arguably, we should remove that trait and instead move these methods to ModuleLoader trait since most implementors will make their module loader a source map getter anyway. Then the logic in deno_core needs to change to first look up module in the ModuleMap and using V8 APIs check if the source map is embedded in the code or uses a URL to link to a source map. Only in the latter case we should delegate to the ModuleLoader to fetch us a source map from provided URL.