¿Qué diablos es un administrador de paquetes? | trucos CSS

Si mantiene un resultado, hasta ahora en esta guía de npm hemos desarrollado un entendimiento común de lo que es npm, en particular, que significa Node Package Manager. En el proceso, discutimos la importancia de la línea de comando y cómo usarla con npm.

También observamos específicamente "n" en npm - Node - y aprendimos que Node es muy similar al código JavaScript que escribimos para ejecutar sitios web en un navegador. En realidad nodo es JavaScript; simplemente funciona fuera del navegador y puede hacer cosas diferentes a las de su contraparte basada en el navegador.

Capítulos del manual

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

¿Qué entendemos por "paquete"?

Ahora dirijamos nuestra atención a las dos últimas letras en npm, a saber, la sección "administrador de paquetes". Para comprender completamente qué es npm, necesitamos saber qué es un administrador de paquetes. Entonces, por supuesto, para comprender esetenemos que averiguar qué diablos es un "paquete".

"PaqueteEs un término general para cualquier archivo de código externo que descargue a un proyecto y use de alguna manera. tal vez usaste jQuery, Orejao Axios en un proyecto en el pasado Estos son ejemplos comunes de paquetes.

Los llamamos "paquetes" porque están "empaquetados" y listos para usar. Algunos idiomas las llaman por otros nombres (Ruby las llama "gemas" por ejemplo), pero el concepto es el mismo. A riesgo de simplificar demasiado, a paquete es un código que no escribiste, pero que recibiste de alguna fuente pública para usar en tu proyecto. Ya sabes, un código de terceros.

O, si prefieres parodias musicales para tus recursos mnemotécnicos:

🎵 Cuando hay un código que eliges
🎵 No es tuyo, pero lo usas.
🎵 este es un paquete
🎵 Cuando es algo que instalas
🎵 que importas y llamas,
🎵 este es un paquete

Los paquetes también se denominan a menudo "dependencias" debido al código que escribe Depende código escrito con jQuery $ no funcionará correctamente si jQuery no está cargado, por ejemplo. (Por esta razón, los administradores de paquetes también se denominan a veces "administradores de dependencia").

Los paquetes pueden ser grandes o pequeños en términos de la cantidad de código que contienen. El paquete puede hacer algo enorme que cambia la forma en que escribe todo el proyecto (como un marco completo), o puede hacer algo muy pequeño y enfocado que se dispersa solo donde se necesita (como un widget o un asistente de tareas).

Usar paquetes sin un administrador de paquetes

Lo más probable es que si ha usado un paquete en el pasado, lo acaba de aplicar con una etiqueta de secuencia de comandos HTML que se extrae de una URL externa (idealmente de un CDN). Así es como puede incluir jQuery en el HTML de su sitio:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

Otro enfoque es descargar una copia del paquete, agregarlo a sus archivos de proyecto y vincularlo localmente de la siguiente manera:

<script src="https://css-tricks.com/jquery.min.js"></script>

Qué deciden los administradores de paquetes

Estos dos enfoques han funcionado bien durante años. Es simple Es limpio Generalmente le permite "configurarlo y olvidarse" del paquete. Entonces, ¿por qué necesitarías algo más?

Probablemente pueda imaginar lo poco atractivo que puede parecer tener un automóvil para alguien que tiene fácil acceso a un transporte conveniente o que no necesita viajar largas distancias).

Si tiene fácil acceso a un transporte público conveniente y eficiente, entonces pagar un alto precio por una máquina enorme que tiene que almacenar en algún lugar, limpiar, mantener y repostar regularmente con combustible costoso probablemente no le traerá muchos beneficios desde su punto de vista. en este caso particular, los beneficios son insignificantes, los costos son relativamente altos. Alguien en esta posición hipotética puede incluso preguntarse por qué alguien quiere un automóvil.

Señalo esta analogía porque aprender sobre nuevas tecnologías puede ser muy difícil cuando resuelve un problema que no tienesdel mismo modo que comprar un coche puede no solucionar el transporte que ya tienes. Puede parecer un gasto enorme e innecesario.

Entonces, lo que decida el administrador de paquetes es más una cuestión de problemas de escalado y procesamiento. Simplemente vincular a un paquete en una etiqueta de secuencia de comandos funciona bien, siempre que:

• la cantidad de proyectos que tiene es manejable;
• el número de personas que trabajan en los proyectos es manejable;
• la cantidad de actualizaciones que deben realizarse en los paquetes es manejable; y lo mas importante,
• cada paquete utilizado en sus proyectos es JavaScript o CSS por parte del cliente (navegador).

el ultimo es más importante porque hay muchas herramientas que nunca podrás usar si solo lanzar cosas en el navegador (más sobre eso en un momento).

Si tu hacer marque todas estas casillas, es posible que nunca supere este enfoque. Su enfoque de desarrollo puede verse así:

Pero incluso en este caso, cuando tienes varios <script> etiquetas, cada una de las cuales se vincula a una versión específica de un script o biblioteca, la solo una forma de obtener cierta visibilidad de los paquetes que está utilizando, y si están actualizados, es abrir el HTML manualmente y mirar el código.

Este no es un gran problema en sí mismo, pero es un problema que crece exponencialmente con el tamaño y el alcance del proyecto. Es posible que pueda rastrear varios paquetes manualmente, pero ¿cómo podría hacerlo cuando estamos hablando de cientos, si no miles, de paquetes? E incluso si puede rastrearlos manualmente, aún presenta un alto riesgo de error humano.

El trabajo de HTML no debe ser una fuente de verdad para todos los paquetes usados ​​en un proyecto. Además de mezclar miedos, también introduce potencialmente conflictos cuando intenta unir trabajo no relacionado entre compañeros de equipo.

Todo esto es importante, pero es la parte más pequeña de un problema mayor. Comprenda que JavaScript probablemente no esté en el lado del cliente solo el tipo de paquete que querrá incluir en sus proyectos para siempre, incluso si es ahora, y ahí es donde están las cosas De Verdad comienzan a desintegrarse.

Muchas aplicaciones de fabricación utilizan algunas, si no todas, las combinaciones de las siguientes herramientas y paquetes:

• Sass (hace que escribir CSS sea más fácil)
• PostCSS (mejora CSS para máxima eficiencia y compatibilidad)
• Babel (traduce JavaScript más reciente para que funcione en navegadores más antiguos)
• TypeScript (agrega verificación de tipos a JavaScript)
• Vuelva a cargar un punto de acceso del servidor de desarrollador que actualiza automáticamente el navegador para mostrar sus cambios
• Utilidades adicionales para agrupación, minimización y/o concatenación de código
• Compresión automática de imágenes
• Bibliotecas de prueba
• linters

Todo esto suena genial, ¡y lo es! - pero fíjate que ya tienes muchas adicciones que no son sólo No están presentes en sus etiquetas de script, pero son no se informa en ninguna parte de su proyecto!! No hay forma de que nadie, incluido su futuro yo, tenga idea de qué herramientas se han utilizado o se necesitan para lanzar este proyecto.

E incluso si pudiera saber exactamente qué necesita el proyecto de esta manera, aún tendrá que ir a buscar, descargar e instalar todos estos paquetes usted mismo... manualmente. Dependiendo del proyecto, esto puede ser fácilmente una tarea para todo un día o más.

Todo esto significa que su flujo de trabajo ahora se parece un poco más a esto:

A pesar de lo convenientes que son todas las herramientas anteriores, aún las necesita gestionar ellos. Las dependencias también son proyectos y proporcionan actualizaciones para corregir errores e introducir nuevas funciones. Como tal, no es realista simplemente colocar una etiqueta de secuencia de comandos en HTML con un enlace que apunta al paquete en la CDN y luego decir que está bien. para asegurarse de que todo esté instalado y funcionando correctamente no solo en Tuya máquina, sino también la máquina de cada colaborador.

Los administradores de paquetes existen para hacer que los paquetes, o dependencias, de un proyecto sean manejables, sabiendo qué está instalado, qué está disponible para actualizar y si un paquete puede entrar en conflicto con otro. Y la belleza del administrador de paquetes es que logra todo esto directamente desde línea de comandos, con el mínimo esfuerzo.

Muchos administradores de paquetes, especialmente npm, también brindan características adicionales que abren aún más oportunidades para un desarrollo más eficiente, pero la administración de paquetes es la atracción principal.

Hay gestores de paquetes que no son npm

Esta parte no es muy relevante para npm en sí, pero para completar, también debo mencionar que npm no es solo Administrador de paquetes JavaScript. Por ejemplo, puedes ver Hilo recomendado en ejemplos de código. Yarn y npm funcionan de manera muy similar, hasta el punto de que se incorpora deliberadamente un alto grado de interoperabilidad entre los dos.

Algunas personas prefieren un administrador de paquetes a otro.Personalmente, creo que las diferencias entre npm e Yarn eran más pronunciadas al principio, pero ahora los dos son más similares que no.

Puede ver ejemplos de código (incluidos algunos en artículos de CSS-Tricks) que se refieren a ambos yarn y npm Esto es para informar al lector que cada uno de los dos enfoques es bueno, en lugar de tener que usar ambos juntos.

La sintaxis de Yarn y npm a veces difiere, pero cuando solo uno está presente, generalmente es trivial convertir un comando o proyecto de uno a otro. Funcionalmente, rara vez (si es que lo hace) importa cuál use, excepto, por supuesto, que cualquiera que trabaje en el mismo proyecto querrá usar el mismo para garantizar la compatibilidad y la coherencia.

Si bien npm e Yarn constituyen la gran mayoría de los administradores de paquetes que usan los desarrolladores, hay otro administrador de paquetes llamado PnPm esto es npm efectivo, pero más eficiente y efectivo. La compensación es que PnPm requiere un poco más de conocimientos técnicos en algunos casos, por lo que es una opción un poco más avanzada.

Qué hace que npm sea un administrador de paquetes "estándar"

Nuevamente, solo menciono otros administradores de paquetes para ilustrar que npm no es el único administrador de paquetes, sino que generalmente es el estándar.

¿Qué lo convierte en un "estándar" entre los administradores de paquetes? Otros lenguajes, incluidos Ruby y PHP, han tenido administradores de paquetes durante muchos años; JavaScript realmente no tenía ninguno bueno antes de npm.

npm comenzó como un proyecto independiente de código abierto, pero fue adquirido por Microsoft en 2020Técnicamente, consta de dos partes: el administrador de paquetes en sí y el registro de paquetes, que es una lista cada vez mayor de casi dos millones paquetes disponibles para la instalación.

Puede pensar en npm como una tienda de aplicaciones para cualquier cosa que desee usar en un proyecto front-end o basado en nodos. Encuentre lo que desea e instálelo en su sistema a través de la línea de comando. Puede actualizar este paquete cuando se publique una nueva versión o eliminarlo por completo si el proyecto ya no depende de él.

Nota para npx

poder también ver npx comandos volando allí. npx es en realidad parte de npm, pero a través del uso npx al mando en su lugar npm puede ejecutar el código del paquete sin que permanentemente permanentemente su instalaciónNPX simplemente instala lo que necesita, lo inicia y lo descarta.

Esto es útil si, por ejemplo, desea ejecutar un script de instalación. En lugar de descargar el instalador, entonces al ejecutarlo, npx le permite simplemente ejecutar el instalador directamente sin dejar nada en su máquina después.Es como los invitados de la casa limpiando ellos mismos.

Otro gran ejemplo: puedes ejecutar npx sass (junto con los argumentos de entrada y salida necesarios) si desea compilar los archivos Sass de su proyecto solo una vez, sin tener que preocuparse por instalar Sass por completo. Esto probablemente no sea práctico en la mayoría de los casos, pero si solo necesita una no compilación rápida aquí y allá, npx sería una forma conveniente de hacerlo, ya que significa menos paquetes instalados que deben actualizarse y mantenerse.

Qué sigue

De acuerdo, eso es una inmersión profunda en lo que queremos decir cuando llamamos a algo un administrador de paquetes. En el caso de npm, se usa específicamente para instalar y administrar paquetes de Node, herramientas que ayudan a agregar funciones a un proyecto, agregar funciones fáciles de usar... ¡o todo lo anterior!

Entonces daremos nuestro primer paso utilizando npm. Y para hacer eso, necesitamos instalarlo en nuestro sistema. Este es el siguiente en esta guía completa de npm.