Tslint: no se debe recomendar la interfaz sobre el tipo literal

Lo siento, no entiendo lo que quieres decir. ¿Es esta una solicitud de función o un informe de error?

El valor predeterminado para interface-over-type-literal enrecomendado.ts es verdadero. Creo que debería ser falso. No estoy seguro si eso constituye una solicitud de función o un error :-)

Después de todo, el preajuste recomendado es obstinado. Incorpora mejores prácticas y sugerencias como la que publicaste anteriormente.
Al ampliar un preajuste, puede anular la recomendación y ajustar la configuración a sus necesidades.

De todos modos, deshabilitar la regla sería un cambio importante. Así que no espere ningún cambio antes de la próxima versión principal.

Para aclarar: interface-over-type-literal solo se queja de las declaraciones de alias de tipo.

type Foo = {foo: number}; // The rule disallows this
interface Foo {foo: number} // and fixes it to this

let obj: {foo: number}; // This is still allowed

Dado que un alias de tipo y una interfaz se pueden usar (casi) indistintamente, no veo por qué preferiría el alias de tipo.

En una nota relacionada: las interfaces solían almacenarse en caché, mientras que los tipos anónimos, como los alias de tipo, se volvían a calcular para su uso. Por lo tanto, el uso de alias de tipo podría aumentar significativamente el tiempo de compilación.
Esa brecha de rendimiento casi desaparecerá con la próxima versión mecanografiada.

Sé que puedo anularlo, pero creo firmemente que la recomendación es incorrecta.

Aquí está mi punto de vista. Hay muchos casos en los que no se puede usar una interfaz para un alias de tipo. Solo puede usar una interfaz para escribir un objeto literal. Si debo seguir las mejores prácticas recomendadas, entonces en un archivo de clase particular donde puedo tener varios alias de tipo, algunos serán alias de tipo y otros serán interfaces. Alguien que se tropiece con esta clase se preguntará qué diablos está pasando y si tengo la intención de que las interfaces se implementen/extiendan en alguna parte, o al menos espero que sea una posibilidad.

En mi opinión, sería mucho más limpio usar un alias de tipo para un alias de tipo y una interfaz para una interfaz, en lugar de sustituir uno por el otro en algunos casos solo porque las interfaces tienen alguna capacidad adicional (que no necesito si todo lo que queremos es un tipo de alias).

Supongo que debería escribir un problema contra los documentos mecanografiados, lo cual haré, pero creo que aquí se puede aplicar algún juicio de ingeniería en lugar de implementar una regla solo porque los documentos dicen que debería hacerlo.

En mi opinión, debería desaconsejarse el uso de la palabra clave de interfaz para estructuras. Esta regla hace exactamente lo contrario, por lo que no hay forma de que esto pueda considerarse una mejor práctica.

En mi opinión, esta es una de las cosas que mecanografiaron mal, esto confunde el concepto de interfaz, cuya semántica en todos los demás lenguajes con seguridad de tipos que he usado, significa "una colección de métodos/funciones/cosas invocables", con firma de objeto/ tipo pato. El uso de la interfaz debería ser más restrictivo, y realmente agradecería una regla TSLint "interfaz-debe-declarar-solo-funciones", o una menos restrictiva "interfaz-debe-declarar-al menos-una-función"

Las estructuras puras deben declararse con el operador de tipo y extenderse con el operador &. Y el nombre debe comenzar con "T" :-)

@navels Estoy de acuerdo con sus comentarios, creo que tslint:recommended debería eliminar esta configuración de reglas demasiado obstinada como un cambio importante en la próxima versión principal

¿Cómo puedo anular esta opción?

@sibelius en su tslint.json , debajo "rules" , márquelo como false :

{
    "extends": ["tslint:recommended"],
    "rules": {
        "interface-over-type-literal": false
    }
}

Tenga en cuenta que este problema está rastreando la desactivación de la regla en el conjunto de reglas recomendado. Si tiene preguntas generales sobre TSLint, utilice StackOverflow o Gitter.

Aquí alguien habla de este tema https://medium.com/@martin_hotell/interface -vs-type-alias-in-typescript-2-7-2a8f1777af4c

Acerca de sobrescribir la regla, preferiría la opción para forzarme a usar el tipo en lugar de la interfaz o, mejor aún, forzarme a usar el tipo solo si estoy definiendo Props o State en mi reacción. componente.

He estado escribiendo cada vez menos código OOP hasta el punto de que no lo estoy usando en absoluto en mi proyecto actual.
No me gustaría que los principiantes fueran empujados hacia él.

@dandrei y yo solo usamos Interfaces, cuando quiero describir funciones (tampoco uso programación orientada a objetos).

Sí, este definitivamente es incorrecto y, en mi opinión, no debería ser parte de los recomendados, o al menos no debería corregirse automáticamente para que podamos desactivarlo antes de que golpee a nuestros tipos.

La recomendación en realidad rompe el código. Considerar:

type Foo = {
  foo: string
}

interface IndexedObject {
  [key: string]: string
}

function useIndexedObject(object: IndexedObject) {}

const foo: Foo = {foo: "foo"}
useIndexedObject(foo)

El código anterior funciona. Hasta que se aplica tslint --fix y cambia type Foo a interface Foo , la última línea produce el error:

Argument of type 'Foo' is not assignable to parameter of type 'IndexedObject'.
  Index signature is missing in type 'Foo'.

En mi opinión, cualquier regla que rompa el código no debe ser una recomendación. Diablos, ni siquiera debería ser una regla si tiene el potencial de romper el código.

No solo eso, sino que también provoca la regla "las interfaces deben comenzar con 'I'".

error TS2344: ...
Index Signature is missing in type 'SOME INTERFACE'.

así que tengo que usar type .

Si sus aplicaciones tienen mucho uso de type , es un buen indicador de violaciones de los principios SOLID.

Quitar la etiqueta Type: Breaking Change según #4811. ¡Ahora aceptando relaciones públicas!

Entonces, ¿por qué se llama TypeScript, cuando debería llamarse InterfaceScript? 🤣