Index signature is missing in type (only on interfaces, not on type alias)

[RafaelSalguero]

TypeScript Version: 2.2.2

Code

interface IndexType {
 [key: string]: string;
}

interface doesNotWork {
 hola: string;
}
type doWorks = { hola: string };

let y: IndexType;

const correctA = { hola: "hello" };
const correctB: doWorks = { hola: "hello" };
//error should be assignable to y
const error: doesNotWork = { hola: "hello " };

y = correctA;
y = correctB;
y = error; //Index signature is missing in type 'doesNotWork'
y = {... error}; //workaround but not equivalent since the instance is not the same

Expected behavior:
The code should not result on a compiler error since the interface doesNotWork is equivalent to the type { hola: string }

Actual behavior:
Variable error of type doesNotWork can't be assigned to y

[syabro]

Same here for 2.3

[cainlevy]

Seeing this still in 2.4. Here's a playground repro.

This appears to be a bug considering implicit index signatures is listed as a feature of v2.0.

[rafaelkallis]

Any update regarding the issue? Still not fixed as of 2.4.2.

Playground

[RyanCavanaugh]

Just to fill people in, this behavior is currently by design. Because interfaces can be augmented by additional declarations but type aliases can't, it's "safer" (heavy quotes on that one) to infer an implicit index signature for type aliases than for interfaces. But we'll consider doing it for interfaces as well if that seems to make sense

[NN---]

Ryan Cavanaugh (@RyanCavanaugh) Thanx for reasoning. Can I say as a rule of thumb to use 'type' for internal interfaces since I don't need augmentation and 'interface' for external to be able to augment ?

[RyanCavanaugh]

There are some other differences between type aliases and interface that might affect your choice - namely you can extend an interface but not a type alias. So it's not quite that simple, but as rules of thumb go it's not a bad one.

[NN---]

You can extend types through intersection types.
Is there anything I miss here?

// Interface
interface A { x: number; }
interface B { y: string;}

interface C extends A, B { b: boolean;}

var x: C = { b: true, x: 1, y: "" };


// Type
type TA = { x: number; };
type TB = { y: string; };

type TC = TA & TB & { b: boolean; };

var tx: TC = { b: true, x: 1, y: "" };

[Codesleuth]

I have an example where this rule is inconsistent when casting to the expected indexed type:

interface MyInterface {
 a: number
 b: number
}

const doesNotWork: { [key: string]: number } = {} as MyInterface
// Index signature is missing in type 'MyInterface'.

const doesWork: { [key: string]: number } = {} as { a: number, b: number }

Playground link

What is it that is considered different about these that is preventing the first case? Note that this is occurring in 2.7 (see the playground link)

[patrickneugebauer]

I was working on a somewhat related example today and I was pretty confused by the results. I tried to create some related situations so I could understand the rules.

As I understand:

1. A specific type can be saved into a more generic type.
2. A specific interface cannot be saved into a more generic interface. (unexpected)
3. A specific interface can extend an more generic interface.
4. A specific type can be saved into a more generic interface.
5. A specific interface cannot be saved into a more generic type.

I tested this in typescript playground:

// First case (expected)
type A = {
 [x: string]: number
};
type B = {
 x: number
};
const b: B = { x: 1 };
const a: A = b; // no error


// Second case (unexpected)
interface C {
 [x:string]: number
}
interface D {
 x: number
}
const d: D = { x: 1 };
const c: C = d; // error
// Type 'D' is not assignable to type 'C'.
// Index signature is missing in type 'D'.


// Third case (expected)
interface E {
 [x: string]: number
}
interface F extends E {
 x: number
}
const f: F = { x: 1 };
const e: E = f; // no error


// Fourth case (expected)
interface G {
 [x: string]: number
}
type H = {
 x: number
};
const h: H = { x: 1 };
const g: G = h; // no error


// Fifth case (maybe expected?)
type I = {
 [x: string]: number
}
interface J {
 x: number
}
const j: J = { x: 1 };
const i: I = j; // error
// Type 'J' is not assignable to type 'I'.
// Index signature is missing in type 'J'.

[Codesleuth]

Thanks Patrick Neugebauer (@patrickneugebauer) - I had noticed those rules too, and have resorted to using type over interface in the common case, to allow building layers of type interactions without hitting walls of errors like these.

In my example, changing the interface to a type does indeed get around the error.