TypeScript tiene tipado estructural. ¿Qué significa eso en la práctica y dónde te muerde?

El tipado estructural significa que la compatibilidad se decide por la forma y no por el nombre declarado, así que cualquier objeto con las propiedades correctas satisface el tipo. Eso hace los tipos baratos y componibles, pero también significa que dos conceptos sin relación con la misma forma son intercambiables, así que un userId de tipo string se puede pasar donde se espera un orderId de tipo string. La solución habitual es un tipo con marca o una pequeña envoltura que le dé al valor una forma distinta.

Significa que TypeScript compara formas y no nombres, así que si algo tiene las propiedades correctas es asignable, venga de donde venga. Eso es sobre todo un regalo, porque hace que los tipos se sientan como documentación y no como ceremonia. Donde muerde es cuando dos tipos tienen la misma forma pero son conceptos distintos. Todos mis identificadores eran strings sin más, así que pasar un id de usuario a una función que esperaba un id de pedido compilaba perfectamente y fallaba en producción. Lo arreglé con tipos con marca, una intersección con una etiqueta única que solo puede producir una función constructora, para que el compilador deje de tratarlos como lo mismo. La otra trampa es que los tipos se borran, así que nada comprueba la respuesta de una API en tiempo de ejecución. Parseo todo lo que cruza una frontera con un validador de esquema y dejo que el tipo inferido fluya desde ahí, lo que significa que el tipo y los datos reales no pueden separarse. Y sé que la comprobación de propiedades sobrantes solo aplica a literales de objeto recién creados, lo que explica mucha confusión sobre por qué un campo extra a veces es un error y a veces no.