null extends object inconsistent between ts and d.ts

[remcohaszing]

TypeScript Version: 3.5.3

Search Terms: null extends object

Code

export type SchrodingersCat = null extends object ? 'alive' : 'dead';

Expected behavior:

SchrodingersCat is either 'dead' or 'alive'.

Actual behavior:

If the code is in a file named box.ts, SchrodingersCat is 'dead'. If the code is in a file named box.d.ts, SchrodingersCat is 'alive'.

Playground Link: N/A

Related Issues: N/A

[MartinJohns]

I can not reproduce this behavior with TypeScript 3.5.3 or 3.6.2. It makes no difference whether it's in a .ts file or a .d.ts file. But it does make a difference whether you have strictNullChecks enabled or not.

Can you make sure that strictNullChecks is enabled in both cases?

[remcohaszing]

The behaviour as described by @MartinJohns is correct.

Toggling strictNullChecks in the tsconfig.json compilerOptions changes the value of null extends object for .ts files, but for .d.ts files null always extends object.

[sandersn]

I could only repro this at first, but it turned out that my tsconfig with strictNullChecks on only included my .ts file. It didn't include my d.ts file, which caused the type to be different. Can you check to see if that's what is happening? Once I got both files covered by the same tsconfig, they started behaving the same.

[remcohaszing]

box.ts

In the TS file, SchrodingersCat is always 'dead'.

export type SchrodingersCat = null extends object ? 'alive' : 'dead';

---

box.d.ts

In a DTS file which has a matching TS file, SchrodingersCat is always 'alive'.

export type SchrodingersCat = null extends object ? 'alive' : 'dead';

---

box2.d.ts

In a DTS file which has no matching TS file, SchrodingersCat is always 'dead'.

Creating an empty file named box2.ts, turns SchrodingersCat to 'alive'.

export type SchrodingersCat = null extends object ? 'alive' : 'dead';

---

package.json

{
  "dependencies": {
    "typescript": "3.6.3"
  }
}

---

tsconfig.json

Setting "strictNullChecks" to false, turns SchrodingersCat to 'alive' everywhere.

{
  "compilerOptions": {
    "strictNullChecks": true
  }
}

issue.zip

[sandersn]

I'm pretty sure that's because when you don't explicitly list files in your tsconfig, and you have box.ts and box.d.ts, only box.ts is part of the compilation.

@sheetalkamat can you confirm?

[sheetalkamat]

@sandersn yes. .ts file takes precedence over .d.ts

c:\temp\test4>dir
 Volume in drive C is OSDisk
 Volume Serial Number is F41A-DBC9

 Directory of c:\temp\test4

09/25/2019  09:24 AM    <DIR>          .
09/25/2019  09:24 AM    <DIR>          ..
09/25/2019  09:23 AM                69 box.d.ts
09/25/2019  09:23 AM                69 box.ts
09/25/2019  09:24 AM                69 box2.d.ts
09/25/2019  09:23 AM                51 tsconfig.json
               4 File(s)            258 bytes
               2 Dir(s)  798,106,771,456 bytes free

c:\temp\test4>node c:\TypeScript\built\local\tsc.js --listFiles
c:/TypeScript/built/local/lib.d.ts
c:/TypeScript/built/local/lib.es5.d.ts
c:/TypeScript/built/local/lib.dom.d.ts
c:/TypeScript/built/local/lib.webworker.importscripts.d.ts
c:/TypeScript/built/local/lib.scripthost.d.ts
c:/temp/test4/box.ts
c:/temp/test4/box2.d.ts

[ljharb]

um, shouldn’t it be dead everywhere because null doesn’t extend object?

[remcohaszing]

Despite my love for cats, I agree logically this one should be 'dead'.

However, most of the ecosystem is non-strict. By this I mean all type definition files published to npm. This means it could be a massive breaking change. Making the cat always 'alive' would only affect unpublished source code where strictNullChecks is enabled. DefinitelyTyped is probably a good test case to see the real impact of changing such behaviour.

This could also affect the decision to eventually enable strictNullChecks by default per #54500 (comment).

[sandersn]

@ljharb null: any when strictNullChecks is off; it's only null: null with it on. So the type system doesn't know that null is actually null and gives wrong answers here. Advanced types often don't work as expected with strictNullChecks off.

@remcohaszing I checked this again and the difference in .d.ts files is also whether strictNullChecks is true or false, not whether it's in a .d.ts file or not. I'm going to close this bug.

[ljharb]

@sandersn ok, but when strictNullChecks is on, null extends object should be false, right?

[sandersn]

Yep, it's 100% "dead" with strictNullChecks on, because null and undefined are not subtypes of object (they are siblings with {} right at the top).