Node 20: errors produced by `reportTSError` are not serialised correctly when using ESM loader

[danrr]

Search Terms

Node 20, reportTSError, error

Expected Behavior

When using the ts-node/esm loader with Node 18, TS errors are reported correctly. The file below when run with node --experimental-loader ts-node/esm test.ts

const a = (b: 1 | 2) => b + 1

console.log(a(3))

produces the following correct error:

TSError: ⨯ Unable to compile TypeScript:
test.ts:3:15 - error TS2345: Argument of type '3' is not assignable to parameter of type '1 | 2'.

3 console.log(a(3))
<stack trace>
  diagnosticCodes: [ 2345 ]

Actual Behavior

On Node 20, the error is serialised to only retain diagnosticCodes and no other info

node:internal/process/esm_loader:42
      internalBinding('errors').triggerUncaughtException(
                                ^
{ diagnosticCodes: [ 2345 ] }

Likely related to https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V20.md#custom-esm-loader-hooks-run-on-dedicated-thread

Steps to reproduce the problem

Run command above on Node 20

Minimal reproduction

TypeStrong/ts-node-repros#33

https://github.com/TypeStrong/ts-node-repros/actions/runs/5057165129/jobs/9075579140

Specifications

• ts-node v10.9.1
• node v18.16.0
• TS compiler v5.0.4

and

• ts-node v10.9.1

• node v20.2.0

• TS compiler v5.0.4

• package.json:

{
  "type": "module",
}

• Operating system and version: MacOS 13.4
• If Windows, are you using WSL or WSL2?:

[cspotcode]

I think you're right, the errors are being marshalled from one thread to another, so our INSPECT_CUSTOM is being lost.

ts-node/src/index.ts

Lines 432 to 464 in 7af5c48

	/**
	* TypeScript diagnostics error.
	*/
	export class TSError extends BaseError {
	name = 'TSError';
	diagnosticText!: string;
	diagnostics!: ReadonlyArray<_ts.Diagnostic>;
	constructor(
	diagnosticText: string,
	public diagnosticCodes: number[],
	diagnostics: ReadonlyArray<_ts.Diagnostic> = []
	) {
	super(`⨯ Unable to compile TypeScript:\n${diagnosticText}`);
	Object.defineProperty(this, 'diagnosticText', {
	configurable: true,
	writable: true,
	value: diagnosticText,
	});
	Object.defineProperty(this, 'diagnostics', {
	configurable: true,
	writable: true,
	value: diagnostics,
	});
	}
	/**
	* @internal
	*/
	[INSPECT_CUSTOM]() {
	return this.diagnosticText;
	}
	}

Can you think of a good solution here? Is there a way to rehydrate the errors on the main thread so that they're logged correctly?

As far as I remember, they errors are never "caught" per-se, they simply have a custom formatting. So when node prints them to stdout, they are formatted the way we want.

[danrr]

OK, I understand, so it's the correct exception, hence the { diagnosticCodes: [ 2345 ] } output but the diagnosticText is being lost in the serialisation of the exception.

I had a look at the code in https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js and I think I see what's happening.

The if on line https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#LL119 is skipped as the type is [object Object], not [object Error].

The if on line https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#L137 is skipped because ObjectPrototypeHasOwnProperty(error, customInspectSymbol) returns false -- the check here is done using Object.prototype.hasOwnProperty but, because the error is created from TSError, the INSPECT_CUSTOM is a property of the prototype of the error, not of the error itself. .

This means it falls into the try block here https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#LL145 which only serialises the diagnosticCodes (as that's the only own property on the TSError).

The fallback on https://github.com/nodejs/node/blob/main/lib/internal/error_serdes.js#LL150 actually serialises it correctly but it's never reached normally as the block above returns.

I tried to change TSError to move

  this[INSPECT_CUSTOM] = () => {
      return this.diagnosticText;
    }

to the constructor, which caused it to serialise correctly and deserialise to an object with the inspect output of TSError as its inspect output. BUT the output from node is now this:

node:internal/process/esm_loader:42
      internalBinding('errors').triggerUncaughtException(
                                ^
[Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

from this line https://github.com/nodejs/node/blob/main/lib/internal/process/esm_loader.js#L42.

I even put console.log("loadESM", err) on the line above the call to internalBinding('errors').triggerUncaughtException and that printed the TSError output correctly, so I'm not sure what is happening.

I tried to set process.setUncaughtExceptionCaptureCallback() but I think I ran into #2024.

Any idea what's happening with this?

[azasypkin]

Thanks for filing this issue! I just wanted to mention that it makes debugging the tests running with Node.js's Test Runner (node --loader=ts-node/esm --test ./src/tests.ts, from secutils-web-scraper) incredibly painful, as it is common to rely on errors while writing tests. One has to switch to Node.js 18 just to see the actual error.

[danrr]

@cspotcode serialisation has been fixed in the nightly version of Node. The problem is that internalBinding('errors').triggerUncaughtException( ignores Symbol(nodejs.util.inspect.custom) but with process.setUncaughtExceptionCaptureCallback(console.error) the type error info is shown again in the console.

[danrr]

@cspotcode Node 20.4 is out now with the serialisation fix in place. Could you please release a new version of ts-node so it can be used like this?

//logError.js
import { setUncaughtExceptionCaptureCallback } from "node:process"
setUncaughtExceptionCaptureCallback(console.log)

node --loader=ts-node/esm --import=./logError.js

Unless there's another way of getting this to work that doesn't require the fix in #2025.

[Maikpwwq]

I am using ts-node this way on Node 20 and works. Config ["type": "module"] in package.json, then update tsconfig.json to ts-node's ESM support and pass the loader flag to node in scripts, node --loader ts-node/esm ./index.ts. tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "module": "ESNext", // ES2020
    "target": "ES2020",
    "moduleResolution": "Node",
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "types": ["vite/client"],
    "jsx": "react-jsx",
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true
  },
  "ts-node": {
    "experimentalSpecifierResolution": "node",
    "transpileOnly": true,
    "esm": true,
  }
}

[brianjenkins94]

I am seeing this with:

$ npx ts-node -vvv
ts-node v10.9.1 C:\project\node_modules\ts-node
node v20.6.0
compiler v5.2.2 C:\project\node_modules\typescript\lib\typescript.js

And on Mac:

% npx ts-node -vvv
ts-node v10.9.1 /project/node_modules/ts-node
node v20.6.1
compiler v5.2.2 /project/node_modules/typescript/lib/typescript.js

[Pyrolistical]

Thanks @danrr.

This worked for me on node v20.6.1

//logError.js
import { setUncaughtExceptionCaptureCallback } from "node:process"
setUncaughtExceptionCaptureCallback(console.log)

Full command: node --test --no-warnings=ExperimentalWarning --loader ts-node/esm --import=./logError.js test-*.ts

[Pyrolistical]

Wait, that workaround only correctly logs out the error, but the test passes. How do we also fail the test?

[gsimko]

@Pyrolistical your solution doesn't work for me, I get the "Error [ERR_DOMAIN_CANNOT_SET_UNCAUGHT_EXCEPTION_CAPTURE]: The domain module is in use, which is mutually exclusive with calling process.setUncaughtExceptionCaptureCallback()"

Would it be possible to log the error from reportTSError instead of just throwing it? In my case it didn't even produce the diagnosticCodes or a stack trace or even a line where the error occurred. The ts-node process just hang up and printed

Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

It took some non-trivial amount of effort to figure that the problem is related to this bug report.

[Pyrolistical]

@gsimko i gave up trying to use ts-node/esm and just tsc the test code and ran it normally with node --test

[alpharder]

I also get this when any TSC error happens under the hood:

Restarting 'app.ts server:start'
(node:42858) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("ts-node/esm", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)

node:internal/process/esm_loader:40
      internalBinding('errors').triggerUncaughtException(
                                ^
[Object: null prototype] {
  [Symbol(nodejs.util.inspect.custom)]: [Function: [nodejs.util.inspect.custom]]
}

Node.js v21.1.0
Failed running 'app.ts server:start'

The command is

node --watch --loader ts-node/esm app.ts

ts-node v 10.9.1

[alpharder]

The world was not ready for ESM 7 years ago and isn't yet quite ready