你能在 TypeScript 中指定一个对象字面量的类型吗？

Question

I'm wondering if there is a way to specify an object literal's type.

For example, how would one resolve this code and assign a B literal to an A variable:

interface A {
    a: string;
}

interface B extends A {
    b: string
}

const a: A = {
    a: "",
    b: ""
};

B is an A , so I expect to be able to assign a B where an A is expected. However, the compiler does not have enough context to figure out that I am passing a B as opposed to an illegal A , so I need to specify it.

I don't want to just make the above code compile, I specifically want my intent of "I am assigning a B to an A " to be conveyed to the compiler. I want the type safety of having a B object literal, so if B gets additional properties for example, this should fail to compile again.

I stumbled upon this post when searching for this. One option is to define an identity function as such:

const is = <T>(x: T): T => x;

const a: A = is<B>({
    a: "",
    b: ""
});

This is not ideal as it will run code for the sake of something that is irrelevant after transpiling. Another option is to use a second variable as such:

const b: B = {
    a: "",
    b: ""
};

const a: A = b;

Also not ideal for the same reason, it's code for the sake of a TypeScript check.

@jcalz's proposals:

interface A {
  a: string;
  [k: string]: unknown; // any other property is fine
}

This allows any excess properties to pass, when I just want A and its subtypes to pass. A 's closedness is not the problem, I'm just unable to tell the compiler that I am passing a B where an A is expected.

Turn off --suppressExcessPropertyErrors compiler option

I want to suppress excess properties, the problem is that I'm unable to tell the compiler that these aren't excess properties, they are the properties of a proper subtype.

Is there an equivalent to type declarations for literals? Is there a fundamental design of TypeScript that prevents such a construct from existing?

In a language such as Kotlin, this is trivial:

val a: A = B()

You can separately declare the type of the variable and the type of the runtime object (must be the same type or a subtype).

In case this is an XY problem , the problem I was originally trying to solve looks like this:

const foo = (): A => {
    if (/* condition */) {
        /* some setup.. */
        return {
            a: "",
            b: ""
        }
    } else {
        return {
            a: ""
        }
    }
}

This does not compile because the first return is not explicitly an A , it is intended to be a B which is an A , but I have no way of specifying it as a B without resorting to one of the workarounds I mentioned above. I want something that looks like

return {
    a: "",
    b: ""
}: B

// or

return: B {
    a: "",
    b: ""
}

// or

return {
    a: "",
    b: ""
} is B

It goes without saying that as B type assertions are not what I'm looking for here. I don't want to bypass the type system, I just want to help the compiler check my object literal as a specified type. This problem also applies to parameters:

const foo = (a: A) => {};

foo({ a: "", b: "" })

This fails, because I have no way of telling the compiler that I am passing a B , it thinks I am using excess properties. It only works if I use an extra variable like so:

const b: B = { a: "", b: "" };

foo(b)

Answer 1

Update: the main issue here seems to be that TypeScript does not have a "widening only assertion operator" or an "inline type annotation operator" (eg, return {a: 123} op A should fail but return {a: "", b: ""} op A should succeed). There is an open suggestion for one, see microsoft/TypeScript#7481 but there's no real movement there. If you want to see this happen you might want to go to that issue and give it a 👍 and/or describe your use case if it's more compelling than what's already there. In the absence of an explicit type operator for this, there are strategies and workarounds available.

---

It sounds like you are already aware of the most common options for dealing with this, but you don't like any of them. I have a few other things you can try, but if your restrictions are:

• no changes to your type definitions or annotations
• no changes to the emitted runtime code
• no type assertions

then your options are limited indeed and you might not find any answer satisfying.

---

Background on what's happening:

Object literals are an interesting exception to TypeScript's normal extendible object types. In general, object types in TypeScript are not exact . A type definition like {a: string} only requires that a value must have a set of known properties. It does not require that a value must lack unknown properties . So an object {a: "", b: 123, c: true} is a perfectly valid value of type {a: string} , because it has an a property whose value is assignable to string . So it seems that there should be nothing with your code; your a is indeed a valid A , with or without context.

But of course the compiler complains. That's because you've assigned a fresh object literal to a variable annotated with a type with fewer known properties than the object literal has. And thus it runs afoul of excess property checking , where object types are treated as exact. You can read the pull request implementing this feature and the rationale for doing this . Those issues also detail the suggested workarounds for situations in which the excess property checking is undesired.

---

You've already mentioned making a helper function (eg, return is<A>({...}) ), assigning to an intermediate variable (eg, const ret = {...}; return ret; ), and using a type assertion (eg, return {...} as A ). Here are the other options as I see them:

• Add an index signature you your A type so that it is explicitly open:

   interface A { a: string; [k: string]: unknown; // any other property is fine } const a: A = { a: "", b: "" }; // okay now

• Turn off excess property checking entirely with the --suppressExcessPropertyErrors compiler option (I don't really recommend this because it is such a wide-ranging change)

• Use a union type like A | B A | B instead of A when annotating the type corresponding to the object literal:

   const a: A | B = { a: "", b: "" }; // okay now

  Since B is a subtype of A , the type A | B A | B is structurally equivalent to A , so you can use it in place of A just about anywhere:

   const foo = (): A | B => { ... } // your impl here function onlyAcceptA(a: A) { } onlyAcceptA(foo()); // okay

• use a type assertion just on the extra property, which requires using a computed property name :

   const a: A = { a: "", ["b" as string]: "" }; // okay

  That really isn't any less type safe, but it does end up generating slightly different JavaScript ( {a: "", ["b"]: ""} ), assuming you are targeting a version of JavaScript that supports computed property names.

Everything else I can think of just changes your runtime code more, so I'll stop there.

---

Anyway, hope that gives you some ideas. Good luck!

Link to code