TS regression: Narrowing of MathNodes by type

[ChristopherChudzicki]

Describe the bug
Prior to v11.3 (not sure how far back, but certainly at least 10), MathNode would be narrowed based on its type property:

const doStuffWithMathNode(node: MathNode) => {
  if (node.type === 'FunctionAssignmentNode) {
    // now TS knows that node is a FunctionAssignmentNode and lets you access associated props
    // like node.params
  }
  // back to being a wider MathNode
}

To Reproduce

• working in v11.2 https://codesandbox.io/s/typescript-playground-export-forked-wnelgb?file=/index.ts
• erroring in v11.3 https://codesandbox.io/s/typescript-playground-export-forked-ke8srr?file=/index.ts

[ChristopherChudzicki]

I think this is a consequence of #2772. I haven't thought about it enough, but would be nice if the goals of that PR could be achieved while still allowing the narrowing.,

[josdejong]

Ai, good point.

I think we can solve this by defining functions like isFunctionAssignmentNode as typeguards, and then use

if (isFunctionAssignmentNode(node)) { 
 // ...
}

instead of

if (node.type === 'FunctionAssignmentNode) {
  // ... 
}

anyone interested in working out a fix? Probably by defining typeguards?

[ChristopherChudzicki]

@josdejong Those exist as typeguards already! Apparently I wrote the typedefs for them...not sure why I started using .type more recently instead.

Yes, I think that's a good solution. Feel free to close this.

Might be worth adding a note in the 11.3.0 release notes about this, though. Also, #2772 was missing its PR link in the release notes.

[gwhitney]

Right, #2772 removed the status of MathNode being a discriminated union.

Aren't all the custom type guards already provided? The PR explicitly changed node.type === 'SymbolNode' to isSymbolNode(node) for type narrowing in one test.

But note that providing a series of type guards isn't quite the same as a discriminated union. At least, you now can't handle a Node with a switch statement on its .type property and have it be narrowed in each case, and you can't do exhaustiveness checking on code that handles nodes (TypeScript no longer has any idea what "all the node types" are.)

So the question becomes which is more important: type narrowing just by checking .type, switch statements, and exhaustiveness checking (pre 11.3) or client extensibility of the node hierarchy while having to use custom type guards (post 11.3)? Unless there's some way to extend a discriminated union, which I doubt. @ChristopherChudzicki do the custom type guards cover your use cases?

[gwhitney]

Comments crossed. Sounds like the custom type guards are good enough.

[josdejong]

😂 that is good news!

I've updated the history to note this, good point

[gwhitney]

(And in some sense it means that 11.3 was inadvertently a breaking change, despite not being a major revision number.)

[josdejong]

yes indeed... not an intended one. Sometimes a new feature is a bug at the same time 😅

[gwhitney]

Hmmm, it turns out it would be possible to get both the discriminated union and client extensibility, see the answer to https://stackoverflow.com/questions/46392758/widen-tagged-discriminated-union-in-typescript-in-a-different-module, at the cost that clients that wanted to do so would need to use the declare module 'mathjs' { } syntax that I was previously unaware of. That seems like it would be the best of both worlds, with the only drawback that it would oblige clients that want to add Node types to use a somewhat unfamiliar TypeScript language facility. (We would have to provide an example of this, either in a test or in the examples directory.) Should we revert/replace #2772 with an alternate PR that sets up TypeScript to allow the extension of the MathNode union along the lines covered in the StackExchange answer? Or just leave be the new status quo with no discriminated union for nodes? Just wanted to raise the question since there is surprisingly actually an option that allows unions to be extended, so we could as ChrisopherChudzicki put it "achieve the goals of #2772 while still allowing narrowing" just by checking the .type property.

[josdejong]

Thanks for figuring this out, this is interesting to know.

What are you're opinions @ChristopherChudzicki @mattvague? I don't have a strong opinion on this.