¿Cómo decido si @ types / * entra en `dependencias` o` devDependencies`?

200

Yo uso TypeScript 2 en mi proyecto. Me gustaría usar algunas bibliotecas js, pero también tipificaciones para esa biblioteca. Puedo instalar tipos con simples npm install @types/some-library. No estoy seguro si debería --saveo --save-devellos. Me parece que incluso el archivo Léame de GitHub DefinetelyTyped menciona ambas versiones, pero nunca las explica. Creo que los @types deberían estar devDependencies, ya que los tipos son necesarios para el desarrollo y no se usan en tiempo de ejecución, pero vi muchas veces @types solo dependencies. Estoy confundido.

¿Cómo debo decidir si @ types / * entra dependencieso devDependencies? ¿Hay realmente algunas instrucciones más o menos oficiales?

— kamyl
fuente

¿Está generando un paquete o es un paquete que será utilizado por otros? Tal como lo veo, solo necesita hacer la distinción entre dependenciesy devDependenciesen el último caso.

— Valentin

Hago un juego en js / ts desde cero. Paquete todo con webpack. No hay ningún cajero automático, pero es posible que lo envuelva todo en Electron para que sea independiente algún día. No creo que nadie lo use como una dependencia en su propia aplicación, pero supongo que podría ser posible (piense en mini juegos en juegos de GTA; y mi juego es de código abierto). Aún así, quiero aprender y seguir las mejores prácticas y es la razón principal por la que hago ese juego. Espero haber aclarado mi caso de uso lo suficientemente bien. :)

— kamyl

Sí, tiene sentido, solo quería asegurarme de que mi respuesta original fuera relevante para su caso de uso. Todavía creo que la distinción entre devDependenciesy dependencieses irrelevante cuando se construye un paquete, es algo que también se create-react-appaplica , pero en última instancia depende de usted elegir

— Valentin el

Respuestas:

140

Digamos que está desarrollando un paquete "A" que tiene un paquete @ types / some-module en devDependencies. Por alguna razón, está exportando el tipo desde @ types / some-module

import {SomeType} from 'some-module';
export default class APackageClass {
     constructor(private config: SomeType) {

     }
}

En este momento, los consumidores de TypeScript del paquete "A" no pueden adivinar qué es SomeType, ya que las dependencias dev del paquete "A" NO están instaladas.

En ese caso particular, NECESITA colocar el paquete @ types / * con "dependencias" regulares. Para otros casos, "devDependencies" son lo suficientemente buenas.

— wookieb
fuente

Entonces, ¿implica que si solo uso el tipo en la implementación, su definición de tipo puede ser devDependencies?

— Franklin Yu

Sí @FranklinYu. Tan pronto como aparezca el tipo en el archivo de declaración, debe colocarlo dependencies. De devDependencieslo contrario está bien

— wookieb

Pero un paquete funciona tanto para TS como para JS. Los desarrolladores de JS no necesitan esos tipos para compilar su código. Agregar la definición de tipo dependencieshará que el árbol de dependencias se hinche.

— Tyler Long

@TylerLong Correcto. No es perfecto, pero esa es la realidad. Opcionalmente, también puede usar "Dependencias opcionales", pero creo que a escala puede ser muy molesto.

— wookieb

Si solo está generando un paquete, puede que no sea necesario hacer la distinción entre dependenciesy devDependencies. Esta característica npmes generalmente útil cuando se publica un paquete que puede ser utilizado por otros y no desea enviarles correo no deseado con dependencias redundantes.

Puede haber otros casos de uso en los que dividir dependencias puede ser útil, pero a menos que tenga una necesidad expresa de esto, entonces mi consejo es elegir uno y colocar todo allí. No es difícil dividirlos después si surge la necesidad.

Un ejemplo bien conocido de esta práctica IRL es que create-react-app, por defecto, la placa repelente no expulsada en la que crea coloca todo dependencies, vea este hilo y esta respuesta

— Valentin
fuente

Si no está publicando el paquete, eso es correcto, pero si lo está, no tiene nada que ver con el desarrollo versus el tiempo de ejecución y todo lo que se necesita para construir este paquete versus lo que se necesita para usar este paquete .

— Yogu

@Yogu Es por eso que hice la distinción en primer lugar, así que sí, estoy completamente de acuerdo contigo

— Valentin

No estoy de acuerdo con este consejo. devDependenciesno se instalan cuando lo hace npm install --production(o npm ci --production) y, por lo tanto, no están disponibles al ejecutar el código de producción. Esta es una diferencia muy significativa para un servicio, no solo una biblioteca.

— Brad Wilson el

@BradWilson Tienes un punto, hay muchos flujos de trabajo npm bajo el sol, si tu caso de uso requiere que hagas la distinción, hazlo por todos los medios. Siéntase libre de dar su propia respuesta a este dilema.

— Valentin

He actualizado mi respuesta para mencionar la existencia de otros casos de uso en los que la distinción puede ser significativa y he dado ejemplos del mundo real. ¡Gracias por la respuesta!

— Valentin

En el caso particular de implementar una aplicación Node.js en producción, uno solo quiere instalar las dependencias necesarias para ejecutar la aplicación.

npm install --production o

npm ci --production o

yarn --production

En ese caso, los tipos deben estar en el devDependencies, para evitar que se hinche la instalación.

Observación: Sé que esto fue mencionado en un comentario de Brad Wilson a otra respuesta. Sin embargo, este punto parece digno de ser una respuesta.

— Carsten Führmann
fuente