Switch to new @cspotcode/source-map-support, using trace-mapping

[cspotcode]

Getting test failures because the mapped stack filenames look like this in some tests: (note the /file:/ mid-way through the path)

file:///d/ts-node/tests/esm/file:/d/ts-node/tests/esm/throw error.ts

Full example:

Command failed: node  --loader ts-node/esm \\"throw error.ts\\"
    (node:2859) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time␊
    (Use `node --trace-warnings ...` to show where the warning was created)
    Error: this is a demo
        at Foo.bar (file:///d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/file:/d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/throw error.ts:100:17)
        at new Foo (file:///d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/file:/d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/throw error.ts:98:10)
        at file:///d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/file:/d/Personal-dev/@TypeStrong/ts-node/trace-mapping/tests/esm/throw error.ts:102:1
        at ModuleJob.run (node:internal/modules/esm/module_job:197:25)
        at async Promise.all (index 0)
        at async ESMLoader.import (node:internal/modules/esm/loader:337:24)
        at async loadESM (node:internal/process/esm_loader:88:5)
        at async handleMainPromise (node:internal/modules/run_main:61:12)

[codecov]

Codecov Report

Merging #1729 (faea240) into main (9e25557) will not change coverage.
The diff coverage is n/a.

[jridgewell]

Hi @cspotcode, I just published @jridgewell/resolve-uri v3.0.6 which should resolve your file: issues. You should pick it up by updating node modules.

[cspotcode]

Interesting, my testing tracked the issue down to some faulty logic in source-map-support, so I'm curious what was changed on your end. Did you make it detect whether the input paths are posix paths, not file URI, and if so, also return posix paths instead of file URI?

[jridgewell]

I'm assuming you have a have two file:/d/ URLs in a sourcemap (either a sourceRoot and a mapUrl when constructing the TraceMap, or an absolute sources array and a sourceRoot, etc). TraceMaps resolvedSources uses resolve-uri to join those together, and I didn't properly handle semi-valid file: URLs (they're supposed to be file:///foo/bar/…, not file:/foo/bar/…) when joining.

[cspotcode]

For posterity, here is the fix:
https://github.com/cspotcode/node-source-map-support/pull/38/files#diff-6c09ea90fab3390be21a951054452be687b7de7b791f14e10874f785dc095864R189-R207

In this particular case, the fixes in trace-mapping weren't causing this problem. The repaired logic linked above needed to accept a file URI as the url argument. It was, funny enough, expecting a path instead of a url. When running native ESM modules, node's stack traces use file: URLs instead of absolute paths.

EDIT: not entirely sure if this logic is still required, if trace-mapping guarantees that all sources are coming to us as absolute file URI.

---

Some additional info, for curious readers:

At the time of writing, ts-node provides sourcemaps with file and sources that are absolute paths but not file URIs. (e.g. "file": "/root/project/generated.js") The sourcemaps do not have a sourceRoot. I don't remember the reasons it was implemented this way.

ts-node/src/index.ts

Lines 1546 to 1555 in 9e25557

	/**
	* Update the source map contents for improved output.
	*/
	function updateSourceMap(sourceMapText: string, fileName: string) {
	const sourceMap = JSON.parse(sourceMapText);
	sourceMap.file = fileName;
	sourceMap.sources = [fileName];
	delete sourceMap.sourceRoot;
	return JSON.stringify(sourceMap);
	}

However, source-map-support needs to handle all sourcemaps, not just those that come from ts-node.

[jridgewell]

not entirely sure if this logic is still required, if trace-mapping guarantees that all sources are coming to us as absolute file URI

trace-mapping should handle absolute file paths without issue, just make sure the POSIX and not Windows format.

Might I recommend you switch to using @jridgewell/resolve-uri to perform relative URL joining? It behaves similar to new URL(url, baseUrl), but supports absolute URLs, protocol-relative URLs, absolute POSIX paths, and relative POSIX paths.