Importing arrays from JSON results in incorrect type checking

[dmaretskyi]

TypeScript Version: 3.8.0-dev.20191105, 3.7.2

Search Terms: JSON incorrect type checking

Code

import data from "./data.json";

interface Foo {
  str: string;
}

const a: Foo[] = data.foo; // no error
const b: Foo[] = data.foo; // compilation error

interface Bar {
  bool: string;
}

const c: Bar[] = data.foo; // no error (even though the types don't match)
const d: Bar[] = data.foo; // compilation error

data.json:

{
  "foo": [
    {
      "bool": true,
      "str": "123"
    }
  ]
}

Expected behavior:

Both assignments to a and b shouldn't error. Assignments to c and d should both error.

Actual behavior:

It seems like the first assignment per type is always treated correctly by tsc while the latter ones are all compilation errors. This happens regardless whether the types actually match or not.

Removing the lines with errors results in successfull compilation even though the types don't match.

Repo with example: https://github.com/Marik-D/typescipt-issue

tsc output:

index.ts:8:7 - error TS2322: Type '{ bool: boolean; str: string; }[]' is not assignable to type 'Foo[]'.

8 const b: Foo[] = data.foo;
        ~

index.ts:15:7 - error TS2322: Type '{ bool: boolean; str: string; }[]' is not assignable to type 'Bar[]'.

15 const d: Bar[] = data.foo;
         ~

tsconfig:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "strict": true,
    "outDir": "dist"
  }
}

[RyanCavanaugh]

This is such a weird bug I literally didn't believe the report wasn't missing a typo.

Repros starting at 3.6; can happen with any assignability check that happens twice

import data from "./data.json";

interface Foo {
  str: string;
}

fn(data.foo);
fn(data.foo); // <-- error

function fn(arg: Foo[]) { }

Totally bananas that we haven't gotten another report of this yet.

[weswigham]

So, two things going wrong here. 1. We actually attempt to issue an error on both calls, but for the first, we refine the error location to a property in the json document (because we use fresh literal properties to refine error locations), then toss out the error because it's not for the right file.
2. There error is there at all because the array literal is preventing unfreshness from being propagated through it - so the outer object is unfreshened, but the array and its member objects are not.

[fatcerberus]

It considers the JSON import to be a fresh object literal? Huh. That’s a bit surprising.

[weswigham]

It considers the JSON import to be a fresh object literal?

No, it's very explicitly unfreshed - but that unfreshing is mistakenly prevented from propagating down into the nested object within the array literal.