Manejo De Dependencias En Javascript

Si han trabajado alguna vez con proyectos hechos javascript  y/o Node.js durante los últimos años, seguramente han notado que todos los proyectos tienen siempre un archivo llamado package.json. Este archivo corresponde a la configuración de los módulos del proyecto. En este post se busco explicar algunas de las características mas importantes de los valores que por lo general encontramos en estos archivos package.json.

Inicializando el proyecto

La forma mas fácil de iniciar un proyecto javascript es con un packete npm (node package manager) usando el comando init y la bandera -y para contestar que queremos el default para todas las opciones que el comando pregunta.

npm init -y

El nombre del proyecto se infiere en base al nombre del directorio en el que se encuentra. Si esto no es lo deseado, podemos quitar la bandera –y y configurar las variables manualmente conforme el asistente te va preguntando.

El comando init escribe un archivo package.json en el directorio en donde se ejecuto, el cual contiene un objeto JSON cuyo contenido por defecto se vería así:

{
  "name": "hello-ricardogeek",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Veamos que significan cada uno de los valores en el archivo:

• name Es el nombre del proyecto. Este debe estar siempre en minúsculas y en formato de URL (sin espacios ni caracteres especiales). El nombre puede contener un prefijo con un ámbito (como por ejemplo: @angular/angular-cli), esto realmente es opcional en caso del que el proyecto sea privado, pero si el proyecto esta dispuesto para ser publicado el nombre debe ser único y corresponder a un repositorio npm.
• version Es un numero de versión que debería ser interpretable por un node-semver, el versionamiento semántico es opcional si su paquete será privado, y requerido y de suma importancia si su paquete será publico.
• description Es una descripción para el proyecto. Esta es opcional y muy útil para que su proyecto pueda ser encontrado con facilidad en un repositorio
• main Es el archivo principal para ejecutar el proyecto
• scripts Es un objeto anidado en el cual las llaves son el nombre del script, y el valor el comando que se va a ejecutar al invocar el nombre con npm (ejemplo: npm test). Esto es útil para especificar los scripts que pueden correrse directamente desde la terminal y pueden hacer varias cosas como iniciar, probar o empaquetar el proyecto para ser ejecutado en un ambiente de producción. Es muy probable que esta sea la única sección que necesite de cambios manuales en este archivo.
• keywords Es un arreglo de palabras claves que ayudan a localizar el proyecto en un repositorio. Como un tag.
• author El nombre de la madre o el padre de la criatura 🙂  Se puede definir ademas en este objeto, email, url y nombre. La intención es tener un punto de contacto fácil para con el autor.
• license Espera el nombre de una licencia en formato SPDX. Por defecto es una licencia ISC pero pueden cambiarlo a otra licencia popular que ustedes elijan.

Gestionando las dependencias

Como es del conocimiento popular, para instalar una dependencia en un proyecto de javascript toma un simple comando en la terminal:

npm install la-dependencia

Una de las fortalezas principales de npm es la habilidad de manejar fácilmente las dependencias de los proyectos. Lo normal es que el archivo package.json se centre en su mayoría, ademas de lo que ya examinamos, en el manejo de dependencias. Las dependencias de un proyecto en javascript tienen una clasificación. Ademas de las dependencias por defecto, existen los siguientes tipos de dependencias:

• dependencies Estas son las dependencias por defecto a las que me refería. Aquí es donde las dependencias del proyecto se describen por lo general. Para instalar este tipo de dependencias se usa la bandera –save o bien, ninguna bandera.
• devDependencies Son dependencias que son usadas unicamente cuando el proyecto esta en un ambiente de desarrollo. Por ejemplo, librerías para pruebas y “transpiladores“. para añadir una dependencia de desarrollo debemos agregar la bandera –save-dev al comando arriba mencionado.
• optionalDependencies Dependencias que deben ser tratadas como opcionales por npm. Esto significa que npm no se quejara ni fallara si cuando una de estas dependencias requiera ser instalada no este disponible o algo falle durante la instalación. Para tener una dependencia opcional debemos agregar la bandera –save-optional al comando arriba mencionado.
• bundledDependencies Espera un arreglo de nombres de paquetes, los cuales serán usados por el proyecto. Para instalar este tipo de dependencias se usa la bandera –save-bundle
• peerDependencies Son útiles para especificar que nuestro proyecto es compatible específicamente con una versión de una librería. De este modo, npm mostrará una advertencia cuando alguna de estas dependencias falta. Deben ser agregados manualmente si lo requerimos. Y en las versiones de npm 1 y 2 son instaladas automáticamente, en la versión npm 3 se recibe una advertencia de que la versión requerida de una librería no esta instalada.

Veamos unos ejemplos de la sintaxis de versionamiento dentro de cualquiera de los objetos de dependencias antes mencionados:

•    1.4.2  Significa que se debe instalar exactamente la versión 1.4.2
• ^1.4.2  Significa que se debe instalar la versión mas nueva compatible con 1.4.2
• ~1.4.2  Significa que el versionamiento es flexible, y que el proyecto también funciona con 1.4.3, 1.4.4…
• ~1.4      Similarmente al anterior funciona con 1.5, 1.6, 1.7 etc…
•    1.4.x  Funciona con cualquier parche de la versión 1.4
•    1.x      Funciona con cualquier minor de la version 1
• >=1.4   Funciona con cualquier versión mayor o igual que 1.4
• 1.4.2 2.4.2 Funciona con cualquier versión entre 1.4.2 y 2.4.2.

Ademas podemos especificar rangos de versiones separados por el operador ||

Otras configuraciones

Dentro de nuestro package.json podemos definir algunas otras configuraciones:

• browser: Se usa en lugar de main en caso de que el proyecto este pensado para ser usado en un navegador en lugar de un servidor.
• private: Si es true, entonces el proyecto no sera de alcance publico al repositorio npm.
• engines: Especifica las versiones de Node.js y npm que funcionan con el proyecto
• homepage: La url a la pagina de internet principal del proyecto
• bugs: Una URL a un tracker de bugs que este disponible para los usuarios del proyecto
• files: Es opcional y espera un arreglo con nombres de archivos que serán entregados con el paquete al repositorio cuando el proyecto es agregado a otro proyecto en forma de dependencia.

Vamos… todo muy fácil: