Cómo instalar paquetes npm trucos CSS

¡Hasta ahora estás bastante familiarizado con npm! Hasta ahora, hemos desglosado las tres letras en «npm» para comprender mejor los administradores de paquetes y nodos. En el capítulo anterior, incluso instalamos Node y npm mientras conocíamos Node Version Manager o nvm. El siguiente lugar en esta guía para principiantes de npm es probablemente la razón por la que está aquí en primer lugar: instalar paquetes npm.

Capítulos del manual

1. ¿Para quién diablos es esta guía?
2. ¿Qué diablos significa «npm»?
3. ¿Qué diablos es la línea de comandos?
4. ¿Qué diablos es Nodo?
5. ¿Qué diablos es un administrador de paquetes?
6. ¿Cómo diablos se instala npm?
7. ¿Cómo diablos instalas los paquetes npm? (¡Estás aquí!)
8. ¿Qué demonios son los comandos npm?
9. ¿Cómo diablos se instala un proyecto npm existente?

Un ejemplo rápido

Podemos instalar nuestro primer paquete con npm install mando (o npm i para abreviar), seguido del nombre de los paquetes que queremos agregar a nuestro proyecto. por ejemplo, el Paquete nudo para Sass se llama simplemente «sass», lo que significa que podemos agregar a un proyecto como este (primero, asegúrese de estar en la nueva carpeta que creó para este pequeño proyecto):

npm install sass

¡Eso es todo lo que necesitas! Ingrese esto y npm comienza a trabajar directamente:

Lo que sucede detrás de escena es que npm está tratando de encontrar un paquete con un nombre sass en el registro de paquetes de npm Si encuentra este paquete (lo que hace), npm lo instala en el proyecto de forma automática node_modules una carpeta (más sobre eso un poco) ubicada en la carpeta principal del proyecto, ¡que incluye todo lo que el paquete necesita para comenzar!)

Una vez que empezamos install comando, puede notar que lo hace No ve algo llamado «sass» en la carpeta del proyecto, como era de esperar. Es extraño, sin embargo, que nosotros hacer ver tres elementos nuevos en la carpeta del proyecto: dos archivos JSON llamados package.json y package-lock.jsonmás uno nuevo node_modules carpeta.

¿¡Qué son éstos!? Le pedimos a npm que instalara Sass, no todo eso. Esto no es parte de Sass… ¿o sí? Bueno, así es, pero hay una muy buena explicación de por qué se generaron estos nuevos elementos en la carpeta del proyecto. Veamos lo que acaba de suceder.

Qué sucede cuando instalas un paquete

Cuando instala (o desinstala o actualiza) un paquete, npm hace la mayoría, si no todas, de las siguientes cuatro cosas:

1. Actualizado package.json archivo en su proyecto, si es necesario;
2. actualizado package-lock.json un archivo (llamado «archivo bloqueado») que contiene todas las características técnicas;
3. instala los archivos por lotes reales y cualquier otro paquete del que dependa el paquete original (dentro node_modules carpeta); y
4. realiza una auditoría de los paquetes instalados.

Vamos a repasarlos uno por uno.

package.json y package-lock.json

Estos dos archivos JSON funcionan juntos para proporcionar un registro preciso de todas las dependencias en su proyecto (y todos suyo dependencias y todas las dependencias de sus dependencias, etc.). La diferencia es un poco técnica, pero se explica libremente: el archivo de bloqueo es una instantánea detallada y precisa del árbol de dependencias del proyecto y package.json es una revisión de alto nivel que puede contener otras cosas. Los paquetes principales que instala pueden aparecer en la lista package.jsonpero package-lock.json es donde se traza todo el árbol de las adicciones.

El archivo de bloqueo tampoco debe actualizarse manualmente; solo a través de npm. Así que asegúrese de no confundir el archivo de bloqueo con package.json Archivo.

Cuando comparte o colabora con otros en un proyecto, npm sabe de dónde proviene el proyecto y qué instaló exactamente en el proyecto a través de estos dos archivos. Puede replicar este entorno exactamente en la máquina de todos los demás, gracias a su información. Ambos archivos están diseñados para interactuar con su repositorio de Git y servir como un esquema de dependencia para su proyecto. De esa forma, cuando otro desarrollador de su equipo clone el repositorio y lo inicie npm install comando, npm sabe exactamente qué paquetes instalar, manteniéndolos a usted y a su colega sincronizados.

si abres package.jsonno verá mucho, pero vale la pena echarle un vistazo solo para ver qué está pasando:

{
  "dependencies": {
    "sass": "^1.43.4"
  }
}

Probablemente no verá este número de versión exacto (ya que el paquete se ha actualizado desde que se escribió), pero Deber ver sass listado en JSON dependencies objeto. El número en sí (1.43.4 en este caso) indica la versión específica de Sass que está instalada.

Como tangente lateral breve pero importante: el símbolo del quilate (^) al comienzo del número de versión permite que npm sepa que se permite instalar pequeñas actualizaciones en el paquete. En otras palabras, dígale a npm que el paquete Sass instalado debe ser por lo menos versión 1.43.4pero puede ser mayor 1.x.x versión, siempre y cuando todavía esté por debajo 2.0.0.npm generalmente selecciona la última versión estable cuando se instala el paquete, pero la agrega para permitir actualizaciones ininterrumpidas. Este bit se llama «versión semántica» y esta es una publicación de blog para mí, pero no exclusiva de npm.

Sin embargo, esto cubre ambos archivos JSON. Vamos a hablar de node_modules siguiente carpeta.

node_modules

node_modules es donde vive todo el código del paquete real; en realidad, están instalados sus paquetes Node y todas las cosas que los hacen funcionar. Si abres la carpeta ahora mismo mientras sigues, encontrarás sass carpeta, pero junto con varias otras carpetas.

El motivo de las carpetas adicionales es que cuando instala un paquete, puede ser necesario otros paquetes funcionen correctamente (como claramente lo hace Sass). Entonces, npm automáticamente hace el trabajo duro de encontrar e instalar todas estas dependencias. Como habrás adivinado, estas dependencias también pueden tener otros propias dependencias y así el proceso se repite, y así sucesivamente hasta que terminemos de rastrear el árbol de dependencias a sus ramas más remotas y absolutamente todo lo que necesitamos esté instalado (o hasta que cometamos un error, aunque esperemos que no).

Por esta razón, es común tener un proyecto node_modules subcarpetas en cientos o más que se acumulan rápidamente en términos de espacio en disco. node_modules a menudo puede llegar a ser bastante grave.

Si se pregunta cómo guardaría una carpeta súper grande como node_modules al repositorio del proyecto, aquí hay una nota importante: a diferencia de los archivos JSON, sobre node_modules la carpeta no está destinada a ser comprometida con Gito incluso compartida. De hecho, casi todos los ejemplos de un .gitignore file (el archivo que indica qué archivos Git debe omitir al rastrear archivos) incluye node_modules para garantizar que Git nunca lo toque ni lo rastree.

Entonces, ¿cómo alguien más en su equipo obtiene estos paquetes? npm install (o npm i en resumen) desde la línea de comandos para descargar dependencias directamente desde la fuente. De esta manera, no hay necesidad de confirmar (o descargar) grandes cantidades de datos hacia y desde el repositorio de origen.

Tenga cuidado al instalar dependencias

Esta red masiva de dependencias y sus dependencias tatara-tatara-tatara pueden dar lugar a situaciones en las que una pequeña biblioteca auxiliar de algún tipo que proporciona un servicio útil puede ser adoptada por muchos otros paquetes que a su vez se utilizan en muchos otros paquetes, hasta que finalmente el código original se instala silenciosamente en un porcentaje significativo de sitios y aplicaciones.

Puede sonar descabellado (si no francamente aterrador) que en el proceso de instalación de su único paquete, en realidad puede dejar un montón de otras cosas a través de la puerta. Puede tener ganas de invitar a un nuevo amigo a la fiesta de su casa, quien luego aparece con 20 extraños no invitados. Pero no es tan raro o aterrador como puede parecer, por varias razones:

1. La mayoría de los paquetes npm son de código abierto. Usted y todos los demás pueden mirar fácilmente debajo del capó y ver exactamente lo que hace el paquete. También puede buscar el paquete en el registro (npmjs.com) para ver cuántas veces se instaló, cuándo se actualizó por última vez y otra información relevante. Si un paquete es bastante popular, puede estar bastante seguro de que es seguro.
2. Hay un enorme mundo de funcionalidad que mucho se necesitarán proyectos. Considere el formato de fecha, el procesamiento de solicitudes y respuestas HTTP, la limitación, el desvío o las animaciones, solo como ejemplos rápidos. No tiene sentido seguir inventando la rueda y codificar manualmente estas cosas cada vez que se usan en un nuevo proyecto.
3. Instalar un paquete no es tan diferente de instalar una aplicación en su teléfono o un complemento en un sitio de WordPress. La diferencia es que no obtenemos la misma vista del funcionamiento interno de estas aplicaciones y complementos como lo hacemos con los paquetes, ni qué otros cosas en las que estas aplicaciones y complementos pueden confiar. Es muy probable que incluyan paquetes mucho más pequeños, de una forma u otra.

Un cierto grado de precaución es una buena idea en cualquier entorno donde uno pueda instalar y ejecutar código arbitrario, por supuesto. No me malinterpretes. Estaría mintiendo si dijera que los malos actores nunca han usado este sistema con éxito. Pero sepa que hay muchos procesos para no confundir las cosas. En caso de duda, quédese con los paquetes más populares y estará bien.

También sepa que npm realiza auditorías de seguridad automáticas por usted, lo que nos lleva al último punto de esta sección.

Qué es npm audit?

cuando instalamos sass Anteriormente vimos el siguiente mensaje en la terminal después de que terminó:

found 0 vulnerabilities

Sin embargo, en su lugar, puede ver algunas advertencias, como este antiguo proyecto mío en la siguiente imagen. Decidí ejecutarlo y ejecutarlo npm install (npm i) después de haber permanecido durante al menos varios años. Vamos a ver cómo funciona:

Los paquetes con vulnerabilidades conocidas son llamados por npm auditque se ejecuta automáticamente cada vez que instala un paquete. Si ves un mensaje como este, no lo hagas. también ansioso; Muchas vulnerabilidades, especialmente en la categoría «moderada», conllevan un riesgo muy bajo en el mundo real y solo pueden ser relevantes en situaciones muy específicas. (Por ejemplo, este solo puede ser un método en un paquete, cuando se usa de cierta manera, lo hace vulnerable).

Sin embargo, lo mejor es prestar atención a lo que podamos, qué es lo que npm audit fix el comando es para. Agregar fix al final le dice a npm que continúe y actualice a nuevo versión secundaria en cualquier paquete con alguna vulnerabilidad de algún tipo. La parte de la «versión menor» es importante; las versiones pequeñas no deben contener cambios críticos, solo actualizaciones. Esto significa que Deber asegúrese de ejecutar la actualización de esta manera sin ningún riesgo de interrumpir su proyecto.

Si la ampliación del paquete con un número de versión más pequeño no funciona, puede agregar --force bandera al comando original:

npm audit fix --force

Sin embargo, esta es una maniobra arriesgada. Permitir que npm «use energía» significa que ahora se puede instalar Importante actualizaciones de versiones de vulnerabilidades, lo que significa que puede realizar cambios críticos o introducir incompatibilidades. No recomendaría hacer esto a menos que haya vulnerabilidades críticas que npm audit fix no se puede revertir y está listo y puede tomarse un tiempo considerable para solucionar el problema, si es necesario.

Una última nota sobre este tema: es útil saber que a veces puede solucionar algunos problemas inesperados con proyectos npm eliminando node_modulesy corre de nuevo npm installEsta es la forma de npm de «apagar y encender las cosas», que yo mismo he hecho muchas, muchas veces.

Qué sigue

Ahora que hemos estudiado la madriguera del conejo en detalle sobre cómo funciona npm debajo del capó, volvamos a la realidad. derecho cosas, ¿verdad?