Error: Debug Failure when importing AssertionError from node:assert/strict

[rauschma]

🔎 Search Terms

Error: Debug Failure

🕗 Version & Regression Information

Happened when using tsc v5.4.5 with @types/node. Wasn’t an issue before (older tsc and older @types/node v20.12.12).

⏯ Playground Link

https://github.com/rauschma/tsc-debug-failure

💻 Code

import { AssertionError } from 'node:assert/strict';

Some of my compilerOptions in tsconfig:

"module": "NodeNext",
"moduleResolution": "NodeNext",
"isolatedModules": true,
"verbatimModuleSyntax": true,
"resolveJsonModule": true,

🙁 Actual behavior

Error: Debug Failure.
    at getTypeOfVariableOrParameterOrPropertyWorker (/usr/local/lib/node_modules/typescript/lib/tsc.js:53005:11)
    at getTypeOfVariableOrParameterOrProperty (/usr/local/lib/node_modules/typescript/lib/tsc.js:52974:20)
    at getTypeOfSymbol (/usr/local/lib/node_modules/typescript/lib/tsc.js:53306:14)
    at getTypeOfAlias (/usr/local/lib/node_modules/typescript/lib/tsc.js:53226:358)
    at getTypeOfSymbol (/usr/local/lib/node_modules/typescript/lib/tsc.js:53318:14)
    at getNarrowedTypeOfSymbol (/usr/local/lib/node_modules/typescript/lib/tsc.js:67681:18)
    at checkIdentifier (/usr/local/lib/node_modules/typescript/lib/tsc.js:67808:16)
    at checkExpressionWorker (/usr/local/lib/node_modules/typescript/lib/tsc.js:76261:16)
    at checkExpression (/usr/local/lib/node_modules/typescript/lib/tsc.js:76216:32)
    at checkNonNullExpression (/usr/local/lib/node_modules/typescript/lib/tsc.js:70497:29)

🙂 Expected behavior

No exception (normal operation)

Additional information about the issue

Possibly helpful:

• I initially couldn’t tell what the problem was (in my rather large repo) but Nathan Shively-Sanders suggested I change line tsc.js:53005 as follows. That told me that this problem was about AssertionError.

- Debug.assertIsDefined(symbol.valueDeclaration);
+ Debug.assertIsDefined(symbol.valueDeclaration, Debug.formatSymbol(symbol));

[Andarist]

It repros in the playground too: TS playground. To repro you need to hover over AssertionError. An interesting fact is that the first hover after a source edit triggers the error but the second one doesn't and it renders a good tooltip content.

[Andarist]

Failing test case:

// @strict: true
// @moduleResolution: node
// @noEmit: true

// @filename: node_modules/@types/node/index.d.ts
/// <reference path="assert.d.ts" />
/// <reference path="assert/strict.d.ts" />

// @filename: node_modules/@types/node/assert/strict.d.ts
declare module "node:assert/strict" {
  import { strict } from "node:assert";
  export = strict;
}

// @filename: node_modules/@types/node/assert.d.ts
declare module "assert" {
  function assert(value: unknown, message?: string | Error): asserts value;
  namespace assert {
    class AssertionError extends Error {
      actual: unknown;
      expected: unknown;
      code: "ERR_ASSERTION";
      constructor(options?: {
        message?: string | undefined;
        actual?: unknown | undefined;
        expected?: unknown | undefined;
      });
    }

    namespace strict {
      type AssertionError = assert.AssertionError;
    }

    const strict: Omit<typeof assert, "strict">;
  }
  export = assert;
}
declare module "node:assert" {
  import assert = require("assert");
  export = assert;
}

// @filename: index.ts
import { AssertionError } from 'node:assert/strict';

throw new AssertionError({
  message: 'Hello',
  actual: 3,
  expected: 3,
});

[jakebailey]

The above test crashes even in TS 4.5 (and back even in 4.0 though with a slightly different error). So this most definitely is not a recent regression at all.

[Andarist]

This is an interesting one. So the symbol that leads to a crash is a result of combineValueAndTypeSymbols. That combines a type symbol with a value symbol that is a mapped symbol. Mapped symbols don't have .valueDeclaration so there is nothing to attach onto the resulting combined symbol here. This leads to a crash.

We could propagate checkFlags here so getTypeOfSymbol could call getTypeOfMappedSymbol instead of getTypeOfVariableOrParameterOrProperty but that doesn't solve anything on its own. The combined symbol isn't truly a mapped symbol so it lacks properties that getTypeOfMappedSymbol expects.

I need to think more about it but it seems like more stuff should get propagated onto that combined symbol from the mapped symbol. getTypeOfSymbol here is interested in the type of the value and the value is typed using a mapped type... so - if I'm not mistaken - the only way to get the correct type is to resolve that mapped type symbol (we just can't do it right now since we lost the information required to do that along the way)