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

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,
  }
}

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

@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.

@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.

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

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

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 https://github.com/TypeStrong/ts-node/issues/2024.

Any idea what’s happening with this?

Took me about 20 minutes to come with this solution:

// package.json
"scripts": {
  "test": "TS_NODE_PROJECT=test/tsconfig.json node --test --import=./test/register.js test/**/*.spec.*"
},

// test/register.js
import { register } from "node:module";
import { pathToFileURL } from "node:url";
import { setUncaughtExceptionCaptureCallback } from "node:process";
setUncaughtExceptionCaptureCallback((err) => {
  console.error(err);
  process.exit(1);
});
register("ts-node/esm", pathToFileURL("./"));

// test/tsconfig.json
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "types": ["node"]
  }
}

// test/test.spec.ts
import test from "node:test";
import { deepStrictEqual } from "assert";

import { myfn } from "../lib/utils.ts";

test("test array", () => {
  deepStrictEqual(myfn([1, 2, 3]), [1, 2, 3]);
});

ESM + TypeScript + node is definitely quite tiresome combination 😅

@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.

1. Put this patch in patches/ts-node+10.9.1.patch (you might need to correct the version in file name)

   diff --git a/node_modules/ts-node/dist/index.js b/node_modules/ts-node/dist/index.js
   index c03afbf..0370067 100644
   --- a/node_modules/ts-node/dist/index.js
   +++ b/node_modules/ts-node/dist/index.js
   @@ -94,7 +94,7 @@ exports.DEFAULTS = {
   /**
    * TypeScript diagnostics error.
    */
   -class TSError extends make_error_1.BaseError {
   +class TSError extends Error {
       constructor(diagnosticText, diagnosticCodes, diagnostics = []) {
           super(`⨯ Unable to compile TypeScript:\n${diagnosticText}`);
           this.diagnosticCodes = diagnosticCodes;
   @@ -110,13 +110,8 @@ class TSError extends make_error_1.BaseError {
               value: diagnostics,
           });
       }
   -    /**
   -     * @internal
   -     */
   -    [exports.INSPECT_CUSTOM]() {
   -        return this.diagnosticText;
   -    }
   }
   +
   exports.TSError = TSError;
   const TS_NODE_SERVICE_BRAND = Symbol('TS_NODE_SERVICE_BRAND');
   function register(serviceOrOpts) {
   

2. Add to package.json scripts this:

   "postinstall": "npx patch-package"
   

   It will auto-apply patch on npm install

3. Do npm istall. That’s it, patch applied.

For anyone who just wants to see what the TSC errors are without any fanciness, here’s how I patched ts-node’s TSError impl:

class TSError extends Error {
    constructor(diagnosticText, diagnosticCodes, diagnostics = []) {
        super(`⨯ Unable to compile TypeScript:\n${diagnosticText}`);
        this.diagnosticCodes = diagnosticCodes;
        this.name = 'TSError';
        Object.defineProperty(this, 'diagnosticText', {
            configurable: true,
            writable: true,
            value: diagnosticText,
        });
        Object.defineProperty(this, 'diagnostics', {
            configurable: true,
            writable: true,
            value: diagnostics,
        });
    }
}

Now I can see the error:

node:internal/process/esm_loader:40
      internalBinding('errors').triggerUncaughtException(
                                ^

TSError: ⨯ Unable to compile TypeScript:
src/framework-extras/streaming-file-uploads/streaming-file-upload.model.ts(48,21): error TS2339: Property 'warning' does not exist on type 'LoggerInterface'.

You can use https://github.com/ds300/patch-package for replicating this workaround locally.

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.

I had this error with node 21.7.1 instead of real error:

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

and i started to get correct error messages after adding this to tsconfig.json (found solution from this thread):

"transpileOnly": true,

For anyone who just wants to see what the TSC errors are without any fanciness, here’s how I patched ts-node’s TSError impl:

This is great, thanks for the patch, @alpharder !

Unfortunately, I couldn’t get your patch working as-is.

Do you think that you could also:

1. Add the filename of the file you changed
2. Change the syntax highlighting on your code above to diff and then add - and + lines to the lines that have been removed and added? A bit nicer to be able to check the patch…