Seemingly strange instanceOf behavior with union of errors

[joshgummersall]

Describe the bug

Trying to match the following error union type:

I'd expect each with(instanceOf to properly narrow err, but instead I'm seeing strange types in the handler functions:

Code Sandbox with a minimal reproduction case
https://codesandbox.io/s/keen-tesla-jciu2?file=/src/index.ts

Versions

• TypeScript version: 4.5.2
• ts-pattern version: 3.3.3
• environment: node v14.17.4

[gvergnaud]

Thanks for the report, I fixed it in this commit, I'll followup with a patch release shortly!

[joshgummersall]

@gvergnaud amazing! Thanks for resolving.

[joshgummersall]

I cloned the repo, built it locally, and linked it with my test project. I see the runtime execution is working, but I'm still seeing handlers typed as a union of errors. Attached a quick screenshot of Intellisense in VSCode:

Note that Result.match there is a wrapper, but I'm calling require("ts-pattern").match(err) behind the Intellisense window.

I've definitely got the commit pulled:

And require.resolve is reporting the link is working:

[gvergnaud]

Here is your own codesandbox example using the prerelease including the fix (3.3.4-rc.0): https://codesandbox.io/s/mystifying-mcclintock-53fhk?file=/src/index.ts

It seems to fix your issue, but please try it again on your own codebase (make sure you aren't hitting Typescript's cache). If you still run in the same issue, could you provide another sandbox with a repro case?

[joshgummersall]

Huh - fair enough! The codesandbox definitely works as expected, I'll see if I can figure out why VSCode isn't showing me the right Intellisense. Thanks!

EDIT: https://codesandbox.io/s/hardcore-brook-egf5e may (or may not be) a worthy issue. If I add optional properties to the sub-class Errors, type inference does not work (as before). My initial problem was that the sub-classes had no extra properties, so type inference didn't introduce meaningful behavior. Here, I'd expect the match return type to be string | undefined and the code should compile.

[gvergnaud]

Oh I see, I think that's because a regular error is structurally assignable to your custom one since all of its properties are optional. I'll see what I can do

[joshgummersall]

Makes sense - my use case is maybe unusual. I'm working on implementing https://doc.rust-lang.org/std/result/enum.Result.html in TypeScript, and using match to unwrap the ok/err states, and then using match again to unwrap the error union. Using and matching on custom errors is meaningful, even if they are all assignable to each other. Anyways, I appreciate your time and effort here! This library is really amazing to use.

[gvergnaud]

Ok this time I think I fixed it for real ;) https://codesandbox.io/s/eloquent-feather-u1zvj?file=/src/index.ts you can try the latest RC and if that works for you I'll turn it in a patch version

[joshgummersall]

Looks great, @gvergnaud! Thanks again for all your time & effort.

[gvergnaud]

Released in v3.3.4