JSDoc type is not narrowing a union (but typescript does)

[xPaw]

🔎 Search Terms

jsdoc union type narrow

🕗 Version & Regression Information

v5.8.2

⏯ Playground Link

https://www.typescriptlang.org/play/?filetype=js#code/PQKhCgAIUgBAXApgWwA4BsCGTIBUowICeqiAJogGaQDeAgqgJYBSAzgPYB2AogE6-tekAD6QGLDpwAi2TAB5cAPgC+Ypmy4AlRK1RdWiAsHDhQEaHCRosOfBeKkK1GgHkARgCtEAY3irxGtKyBHCoAqS88ES08LwAroiqrHHe3jqsIbBh7BFRtLiqZMHQxqZgmVGOVLTuXr7+6pJ8AryZ2bnRNJSY6AZJKWmsGfbtiJGdrLGMnADmqmMtRiaUiPDeABYAFJAA5Jg7kACU4AB08OuInNu8OnqcBpAAvIqQN7r6iCcekpuHR6fnS7bMyWEiIWibIrwTAALjUEi0tw+ckmvGmM0Uf2ekEwnCIqhAwEgUMwT0U4BoUEg1MYlG2AEISSdkql0v9qdTKRzuZBvPp2OhPuh2DNtkyFoIjgBuKk816rOK8Tgy7nKEzcgBumCEAGsnsTZCcSTLVIcpUA

💻 Code

Typescript version: https://www.typescriptlang.org/play/?&filetype=ts#code/CYUwxgNghgTiAEAXAngBwQQVQSwFIGcB7AOwCUR9UT8QAeAFQD54BeeLPI4gURhkJjwAPuxwESAESiIoDRgG4AUItCRYCbMUQgYAMyhhMYrlJlz4Ab0Xwb8fAFcwh-PgBcSGPZBLb8YNKh3eiUAX2VVaDh4TW09AyNOEl5+QStfBycKN3h9CBofWx0U93xEGE0Ac1DlXRBEMAALAAp4AHIoVvgASkUAOkQGkGIWuEpqBBZmUapiGl6AKy4mru6+gaGWlv8Zdw5xMgoZmlpS8uIK5hXJxTTbbF0WgEJtqF6M53xV31vfGzBqQgQEC9CCECpbAK9IoCboFX7wOCIewwYhw+Bhay2ABusHgAGtWH5IS9QrCgA

🙁 Actual behavior

Property 'error' does not exist on type 'ApiJsonResponse<string>'.
Property 'error' does not exist on type 'ApiJsonData<string>'.

🙂 Expected behavior

No error, and for the type to be narrowed correctly.

Additional information about the issue

In my actual code, I have the types (same as in the typescript playground link), in a d.ts file. I simply converted them to jsdoc comments for the playground.

It does correctly narrow, if I change it to if( data.success === false )

[snarbles2]

The typescript version has strict null checks enabled. The javascript version does not. Enable strict null checks in the javascript version and the error goes away.

[xPaw]

Is that expected behavior? Is there no way around this without enabling the check?

[snarbles2]

I'm not 100% sure why the type isn't narrowed without strict null checks. If I had to guess, I would say because (!data.success) narrows data.success to false | undefined, whereas (data.success === false) narrows it to false. With struct null checks, you remove undefined from the equation so both options narrow to false.

The "way around this" is to use (data.success === false) or // @ts-ignore. Otherwise, it's just doing as you asked.

[xPaw]

I mean even if I type it as @property {false|undefined|null} success it doesn't want to narrow it down.

[snarbles2]

If my understanding is correct, the lack of strict null checks means undefined is always lurking around the corner which impacts the ability to narrow some things. It doesn't help to add null into the mix when what you really need is to exclude undefined. (data.success === false) does that, as does strictNullChecks, and // @ts-ignore sidesteps it.

[nmain]

Duplicate of #29862.

With strictNullChecks off, it's as if you had written the type as:

type ApiJsonResponse<T> = ApiJsonError | ApiJsonData<T>;

interface ApiJsonData<T> {
    success: true | undefined | null;
    data: T;
}

interface ApiJsonError {
    success: false | undefined | null;
    error: string;
}

With that in mind, clearly if (!data.success) doesn't narrow anything.

[xPaw]

That feels weird to me to be honest, it widens "true" or "false" into also undefined and null.

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[nmain]

@xPaw Yeah, it is weird for sure, but that is the only thing that strictNullChecks does and the whole point of that setting. If you want every single type to have | null | undefined implicitly added to it, you use strictNullChecks: false; if you want types to work as written, you use strictNullChecks: true.