Solución:
Los archivos de declaración describen la forma de las bibliotecas JavaScript externas. Por ejemplo, usando jQuery con $
dará como resultado un error de TypeScript sin archivos de declaración, porque $
o JQuery
es indefinido. Por lo tanto, un archivo de declaración crea una interfaz, por lo que el compilador sabe “si esta variable es de tipo JQuery debe tener las funciones x, y, z”
Al crear interfaces para su proyecto, debe colocarlas donde quiera: dentro de un archivo de interfaz grande, dentro de un archivo individual para cada interfaz, o dentro del archivo al que puede pertenecer, PERO dentro de un archivo de declaración sería muy inconveniente .
Personalmente me gusta tener archivos individuales para cada módulo / clase / interfaz. Pero es solo una cuestión de gustos.
Lo único que está considerando crear un archivo de declaración es brindar a otros desarrolladores la posibilidad de usar su archivo JavaScript final (¡no TypeScript!) En su proyecto.
Otro desarrollador sugirió que pusiéramos [the interface] en un archivo * .d.ts y luego no necesitaríamos importarlo para hacer referencia a él.
Usando un .d.ts
vs. .ts
El archivo no está relacionado con proporcionar una declaración de tipo en un ámbito de script local / módulo o global /.
Usted puede export
La interfaz ErrorFirstCallback
, entonces otros tendrán que import
eso. O no usas export
/import
para convertir el archivo en un script global. Luego, ErrorFirstCallback
se puede utilizar sin una importación. No importa, si el archivo tiene un .ts
o .d.ts
extensión en este caso.
¿Cuándo deberían definirse las interfaces que estamos definiendo en un archivo * .d.ts frente a un archivo * .ts?
Qué lo hace la cuestión es que .d.ts
Los archivos solo se ven como entrada del compilador y no se emiten a su dist
/build
carpeta.
Como regla general, pones el tipo en un .ts
, si desea proporcionarlo como parte de un paquete npm o API de tipo público para facilitar su vida con el paso de compilación (se emitirá como salida del compilador).
Puedes usar .d.ts
archivos para los tipos de su proyecto utilizados internamente.