Broken sourcemap in the stack trace of uncaught errors

[unleashy]

Acknowledgements

• I searched existing issues before opening this one to avoid duplicates
• I understand this is not a place for seek help, but to report a bug
• I understand that the bug must be proven first with a minimal reproduction
• I will be polite, respectful, and considerate of people's time and effort

Minimal reproduction URL

https://gist.github.com/unleashy/6b0956eb7572cafbf0eb5f18c9c491a4

Version

v4.7.0

Node.js version

v20.10.0

Package manager

N/A

Operating system

Windows

Problem & Expected behavior

Run npx tsx foo.ts with the code from the gist:

file:///C:/Programming/js/foo.ts:1
let foo="foo";throw new Error("foo");
                    ^

Error: foo
    at <anonymous> (c:\Programming\js\foo.ts:4:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
    at async loadESM (node:internal/process/esm_loader:34:7)
    at async handleMainPromise (node:internal/modules/run_main:113:12)

Node.js v20.10.0

Basically if an uncaught error is displayed, as per normal node procedure the line of the code where the error was thrown is shown, in the original sourcemap. However tsx dumps the whole contents of the file, minified, into the console. For small files, as in the reproduction, I guess this is fine? But for big files the console gets utterly spammed with completely useless minified code. Curiously, the file paths are correct.

I couldn't get to reproduce this on Stackblitz… so I'm guessing this is some sort of Windows problem? But it doesn't happen with ts-node.

I tested with npm and yarn and both had the same result. And whatever is in tsconfig.json seems to make no difference.

The expected behaviour for me would be for the code displayed in the error trace to only show the line of the affected code, source-mapped to the original Typescript.

Contributions

• I plan to open a pull request for this issue
• I plan to make a financial contribution to this project

[wydengyre]

@unleashy Not just a Windows problem. Same bug for me on MacOS (14.3.1).

[privatenumber]

Thanks for reporting—happy to accept a PR to fix this!

Locking thread to direct further dialogue in the form of PRs.

[privatenumber]

@wydengyre

I believe you were experiencing #478 which was fixed in v4.7.2
I'm guessing most people stumbling across this thread may be confusing this with that too.

@unleashy

Your problem is happening in Node v20.10.0, which means it's not related to #478

I don't have a Windows but it works fine for me on Mac.
Can you provide a reproduction via GitHub Actions CI using a Windows OS?

[privatenumber]

Closing as a reproduction was not provided

[mistaecko]

@privatenumber
I can reproduce on OSX using the steps below. Note that I was not able to reproduce with the OP's example.

nvm use 20
mkdir tsx-issue447 && cd tsx-issue447
npx cdk init app --language typescript
sed -i.bak 's/\/\/ The code.*$/throw new Error("Duh!");/' lib/tsx-issue447-stack.ts
npx tsx bin/tsx-issue447.ts

Output - notice that the file is correct, but location is 2:1366

Error: Duh!
    at new TsxIssue447Stack (/Users/me/tsx-issue447/lib/tsx-issue447-stack.ts:2:1366)
    at /Users/me/tsx-issue447/bin/tsx-issue447.ts:3:950
    at Object.<anonymous> (/Users/me/tsx-issue447/bin/tsx-issue447.ts:4:3)

[privatenumber]

@mistaecko

Thanks, I can reproduce the error with that, but I don't think this is related to what @unleashy reported.

@unleashy's reproduction allegedly errored with a single file.

In your case, the issue comes from import 'source-map-support/register' interfering with the stack trace. source-map-support is an unmaintained package superseded by Node's native source maps: https://nodejs.org/api/cli.html#--enable-source-maps

I'm still interested in the original issue @unleashy is reporting, but I'm going to lock this thread to prevent piling on since it's happened twice already.