El ecosistema de Javascript esta lleno de dependencias, hay mas de las que nos gustaría pero bueno así es el mundo.
Una pregunta constante que me hacen es: ¿Estos deberían ir mis dependencias? ¿dependencies o devDependencies?
Si bien existen otras categorías como peerDependencies, optionalDependencies, bundleDependencies, etc (más información). Su uso no es tan común como el de las que mencionaron.
En lo personal yo tengo un criterio que es el siguiente:
En dependencies van los paquetes que mi proyecto necesita para ejecutarse, en devDependencies van los paquetes que mi proyecto necesita para tooling (construcción, lints, test, etc).
Este es el core de mi razonamiento ... pero hay situaciones o mas bien contexto donde esto necesita ciertos matices y el contexto de lo que se esta construyendo y el entorno donde se va a ejecutar.
Por ejemplo supongamos que instalamos un paquete llamado eslint, ¿sería una dependency o devDependency?
En una biblioteca UI: devDependency
En un plugin de eslint: dependency (aunque también sería una peerDependency)
En una aplicación: devDependency
Eslint no es necesario para que mi aplicación y/o biblioteca se ejecute salvo la excepción de estes haciendo un plugin que haga uso de eslint para ejecutarse.
La importancia de categorizar las dependencias tiene un proposito bastante crucial cuando distribuyes software porque puede permitirte omitir la instalación de ciertos paquetes lo cual hace que el deploymente sea más rápido, en el sentido de que no tienes que instalar mas cosas de lo necesario.
Salvemos al planeta un paquete a la vez :D
Otro ejemplo, Typescript.
En una biblioteca UI: devDependency
En una biblioteca de tipos: devDependency
En una aplicación: devDependency
¿Porqué siempre es una devDependency? Simple, es un compiler, lo necesitas para construir tu software, pero al momento de la distribución no se necesita.
Probablemente si has usado create-react-app con typescript habrás notado que typescript es una dependency, entonces, ¿te acabo de engañar?
No, en el caso de aplicaciones web donde se generaran bundles con las dependencias que se usan y no está hecho para ser distribuido como paquete, la distinción que te mencioné puede que no tenga sentido, al final depende del target donde tu proyecto se ejecute.
Si estuvieramos haciendo un servidor y no usaramos herramientas como babel, ts o cualquier otra herramienta de construcción, unicamente node, al momento de hacer un deploy podría instalar solo las dependencias de producción que necesita mi servidor para poder funcionar y eso haría que todo fuera mucho más rápido, aunque este contexto quizás podría no ser del todo cierto si estas en un monorepo y estas dentro de un workspace.
¿Entonces porque preocuparme esto? ¿Si todo da igual porque leí esto?
Hay varios motivos que no conozco pero si te puedo dar 2 muy concretos, seguridad e identificación para eliminar.
En el punto de seguridad es simple, es preferible tener vulnerabilidades en devDependencies que en una dependency.
Obvio es preferible no tenerla pero el hecho de remover una dependency puede llevarte a modificar código y una vulnerabilidad puede ser explotada ya que esta al alcance del usuario. En una devDependency puede tener vulnerabilidades pero si solo se usan en un scope de construcción y no en lo que llegará el usuario podemos resolverlo sin tanta presión.
NOTA: depende del grado de la vulnerabilidad y el potencial de ser explotada
En el punto de identificación paquetes para eliminar es que hay dependencias que solo utilizamos bajo ciertos contextos, por ejemplo yo uso y recomiendo semantic-release. Cada vez que alguien descarga el proyecto descargan semantic-release, esto no se debe utilizar en local pero al ser una devDependency se tiene que instalar.
Como ya identifique que esto solo se usa en un contexto de un sistema de CI/CD, podría idear muchas estrategias para evitar su instalación, en este caso yo uso github actions así que fácilmente podría remover esas devDependencies y sustituirlas por un action.
Nota: A veces no podemos llegar a estas conclusiones antes de instalar por desconocimiento de la herramienta como es mi caso
Espero les haya gustado, no se les olvide seguirme en twitter o github :D
Top comments (0)