Error.stack type definition in lib.es5.d.ts is incorrect / exactOptionalPropertyTypes incompatible

[voxpelli]

Bug Report

🔎 Search Terms

Error.stack, exactOptionalPropertyTypes, ErrnoException

🕗 Version & Regression Information

• This is a type issue
• This changed in Fix findIndex definition #8705 but it took until the 4.4 release for it to surface, thanks to exactOptionalPropertyTypes and it making Error incompatible with a corrected Error-subclass in @types/node: fix(node): error when exactOptionalPropertyTypes is enabled DefinitelyTyped/DefinitelyTyped#55425
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about es5

⏯ Playground Link

Playground link with relevant code which is valid according to the ECMAScript spec and basically every other JS spec out there as .stack isn't standardized (as far as eg. MDN knows at least)

Edit: @ljharb has an ECMAScript Stage 1 proposal for an Error Stacks spec.

💻 Code

interface MyCoolStack {
    line: string
}

interface MyError extends Error {
    stack: MyCoolStack
}

🙁 Actual behavior

Got error:

Interface 'MyError' incorrectly extends interface 'Error'.
  Types of property 'stack' are incompatible.
    Type 'MyCoolStack | undefined' is not assignable to type 'string'.
      Type 'undefined' is not assignable to type 'string'.

🙂 Expected behavior

One of two:

1. Either that it passes completely...
2. ...or at least that it complains the same as it does with exactOptionalPropertyTypes turned off:

Interface 'MyError' incorrectly extends interface 'Error'.
  Types of property 'stack' are incompatible.
    Type 'MyCoolStack | undefined' is not assignable to type 'string | undefined'.
      Type 'MyCoolStack' is not assignable to type 'string'.

Edit: The ECMAScript Stage 1 proposal for an Error Stacks spec defines that the stack should be of type string|undefined, which makes the current type of stack?:string wrong and should be replaced with stack?:string|undefined if one agrees with that specs view of the current state of Error stacks.

[voxpelli]

Updated with a reference to @ljharb's and @erights' Error stacks ECMAScript proposal, which is currently in stage 1, but is probably the closest to a standard that is currently available and which also looks like a comprehensive research on the subject.

[ljharb]

In JavaScript, any type that forbids extra properties is incorrect, at least as far as most all builtins go, since the spec explicitly mandates that they all be extensible and that implementations be allowed to add extra properties.

stack is a defacto standard unrelated to the stacks proposal; anything hoping to type JS should allow Errors to have a stack string property.

I'm not clear on the actual issue here tho, since the playground link mandates an interface that is not nearly as defacto - and line would be a number, not a string.

[voxpelli]

@ljharb Main issue is that, as defined now, if exactOptionalPropertyTypes is set to true in the tsconfig.json, then .stack is not allowed to be undefined, it only is allowed to be string or not exist at all, as stack?: string and stack?: string|undefined are no longer seen as equal.

Here's a simplified playground:

interface MyError extends Error {
    stack: string|undefined
}

With exactOptionalPropertyTypes set to true, as in that playground, it gives:

Interface 'MyError' incorrectly extends interface 'Error'.
  Types of property 'stack' are incompatible.
    Type 'string | undefined' is not assignable to type 'string'.
      Type 'undefined' is not assignable to type 'string'.

And .stack should be allowed to be undefined

[ljharb]

In what implementation would any error type have an undefined stack?

[voxpelli]

Depends on how people have perceived it and how Error types are used in the community and engines, so I don’t know much more than it arising as an error in DefinitelyTyped/DefinitelyTyped#55425

I also note this in the stage 1 proposal:

If E does not have an [[ErrorData]] internal slot, return undefined.

[ljharb]

That’s for the accessor, if you .call it on a non-error object, for back compat. Fair point tho, that the standard accessor can return undefined.

[MichaelMitchell-at]

Bumping this, as it's a major blocker to enabling exactOptionalPropertyTypes in our code base