By mixing TypeScript types with interfaces in an intersection, I seem to loose the stricter behaviour of interfaces in my code. I want to be able to compose types using intersections (such that I can narrow down a type in specific instances), but I want to be able to keep the exactness of interfaces.
Take this code:
type Vehicle = {
name: string
properties: Record<string, unknown>
}
interface CarProperties {
electric?: boolean
}
type Car = Vehicle & {
name: 'car'
properties: CarProperties
}
const car: Car = {
name: 'car',
properties: {
electric: false,
someOther: 'bs' // <= I want this to throw a TS Error
}
}
As the CarProperties is an interface, I would expect it to disallow the inclusion of the someOther key.
Why is this not the case? And how else would one go about achieving the same thing?
The problem is the intersection type Car. This leads to properties of car being a Record<string, unknown> & CarProperties and thus allows string keys.
To achieve what you want, you can add a generic to your Vehicle type:
type Vehicle<T extends object> = {
name: string
properties: T
}
type GenericVehicle = Vehicle<Record<string, unknown>>;
interface CarProperties {
electric?: boolean
}
interface Car extends Vehicle<CarProperties> {
name: 'car'
}
PS: I noticed you call this a "union type", which it is not. Intersection types share the properties of the intersected types, whereas union types can be either of the unionized types.
You can make electric property a required one and use object type instead of Record<string, unknown>.
type Vehicle = {
name: string
properties: object, // <---- change
}
type CarProperties = {
electric: boolean // is required now
}
type Car = Vehicle & {
name: 'car'
properties: CarProperties
}
// ok
const car2: Car = {
name: 'car',
properties: {
electric: false,
}
}
// expected error
const car4: Car = {
name: 'car',
properties: []
}
// expected error
const car5: Car = {
name: 'car',
}
// error
const car3: Car = {
name: 'car',
properties: {}
}
// error
const car: Car = {
name: 'car',
properties: {
electric: false,
someOther: 'bs' // error
}
}
I know, using object type is controversial a bit, because of this rule, but you can find more information about pros and cons in this answer.
If you have more variants of Vehicle, not only one Car, you may want to remove properties from Vehicle type and create a discriminated union of allowed Vehicles. It is only my guess, since I'm not aware of any other requirements.
It is also worth knowing about excess-property-checks. It will disallow you to provide any other extra properties for literal argument.
If you put all your requirements and test cases into your question I believe you will get what you are looking for