El problema con los paquetes de nodos globales

 

 

 

  • Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Friedman
  • Implemente rápidamente. Implementar inteligentemente

  • Índice
    1. ¿Cual es el problema?
    2. ¿Por qué no debería instalar dependencias globalmente?
    3. ¿Qué puedo hacer al respecto?
    4. ¿Podemos o deberíamos llevar esto más lejos?
    5. Conclusión
      1. Otras lecturas

    Los desarrolladores de JavaScript enfrentaron una gran revolución con Node.js, al permitirles escribir código que se ejecuta directamente en sus máquinas. Comenzaron a escribir fácilmente herramientas para la línea de comandos que automatizan muchas cosas en sus ciclos de desarrollo. npm, que viene incluido con Node.js, hizo esto aún más fácil al brindarles acceso rápido y fácil a herramientas que otros han creado, a las que instalan en sus máquinas para acceder desde cualquier lugar de su sistema. Aprovéchalo al máximo Instalando paquetes desde npm globalmente.

     

    Node.js supuso una gran revolución para los desarrolladores de JavaScript al permitirnos escribir código que se ejecuta directamente en nuestras máquinas; Nuestras habilidades ya no se limitaban únicamente a los navegadores. Al principio, muchos de nosotros simplemente vimos esto como una forma de escribir nuestros servidores de aplicaciones sin necesidad de aprender otro idioma , pero rápidamente nos dimos cuenta de que también podíamos escribir herramientas para la línea de comandos que automatizaran muchas cosas en nuestros ciclos de desarrollo.

    npm, que viene incluido con Node.js, hizo esto aún más fácil al brindarnos acceso rápido y fácil a herramientas que otros han creado, que instalamos en nuestras máquinas para acceder desde cualquier lugar de nuestro sistema. JavaScript era finalmente un lenguaje de programación "real". Pero con estas nuevas capacidades surgieron muchas mejores prácticas que era necesario descubrir, porque había muchos escenarios nuevos que no se encontrarían en el navegador. En particular, me gustaría hablar sobre una práctica que ha estado mucho en mi mente últimamente y que creo que gran parte de la comunidad necesita evaluar.

    ¿Cual es el problema?

    Me refiero específicamente a la instalación de paquetes de npm globalmente usando npm install -g. No me malinterpretes: instalar paquetes globalmente es ciertamente útil y conveniente a veces, pero no siempre lo usamos sabiamente.

    Regla general: si su proyecto depende de un paquete, debe aparecer en su package.jsonarchivo como una dependencia e instalarse localmente en su proyecto, en lugar de globalmente. Las herramientas de las que sus proyectos no dependen ciertamente se pueden instalar globalmente. Por ejemplo, uso UglifyJS como un paquete instalado globalmente para realizar una minificación única de archivos JavaScript cuando el archivo no forma parte de un proyecto más grande o cuando solo quiero compartir un archivo. Otro buen ejemplo sería el paquete http-server , que me permite iniciar un servidor de archivos simple en cualquier directorio que necesite con un simple comando.

    También es posible que puedas salirte con la tuya usando paquetes globales si estás trabajando en un proyecto interno, porque muchas herramientas (como Docker) pueden usar la automatización para neutralizar algunos de los problemas con los paquetes globales. Sin embargo, si estás trabajando en un proyecto público y/o de código abierto, ¡presta mucha atención porque eres el público principal de esta publicación!

    ¿Por qué no debería instalar dependencias globalmente?

    La respuesta corta obvia es que su proyecto depende de ellos. Si su proyecto depende de un paquete, debe documentarlo package.jsonpara que pueda garantizar que se instale cuando alguien escriba npm install. De lo contrario, deberá agregar pasos adicionales en su archivo README para informar a cualquier otra persona que clone su proyecto que también debe instalar cada una de sus dependencias globales.

    Por ejemplo, si su proyecto se basa en Browserify (usaremos Browserify en nuestros ejemplos de ahora en adelante), es posible que haya escrito algunos pasos en su README que se ven así para ayudar a las personas a comenzar con su proyecto:

    Para utilizar este proyecto, siga estos pasos:

    1. git cloneel repositorio.
    2. Correr npm install.
    3. Correr npm install -g browserify.
    4. Corre browserify main.js bundle.jspara construir.

    ¿Por qué obligar al usuario a agregar el paso adicional de instalar Browserify globalmente? Además de simplificar la garantía de que Browserify se instale, agregarlo a su lista de dependencias package.jsontambién garantiza que se instalará la versión correcta de Browserify. Tener la versión incorrecta de una dependencia suele ser tan malo como no tener la dependencia instalada en absoluto. Esto significa que debe incluir la versión de Browserify y cualquier otro paquete global que esté utilizando en su archivo README (no estoy seguro de haber visto a nadie hacer esto). Esto también significa que si actualiza a una versión más reciente de cualquiera de esos paquetes, también deberá actualizar el archivo README con la nueva versión.

     

    Finalmente, incluso si alguien instala la versión correcta de Browserify para su proyecto, es posible que esté trabajando en un proyecto diferente que requiera una versión diferente de esa misma herramienta, lo que causaría conflictos . Es posible que varios de sus propios proyectos incluso utilicen diferentes versiones de Browserify porque lo actualizó cuando comenzó un nuevo proyecto y no regresó para asegurarse de que los proyectos anteriores se actualizaran para funcionar con la nueva versión. Estos conflictos se pueden evitar.

    ¿Qué puedo hacer al respecto?

    La respuesta obvia es que debe evitar usar ese -gindicador cuando instala sus paquetes y comienza a usarlos -So --savepara guardarlos en sus dependencias o -Dpara --save-devguardarlos en sus dependencias de desarrollo. Esta, por supuesto, no es la respuesta completa porque no explica cómo se pueden ejecutar paquetes como Browserify desde la línea de comandos, que fue el objetivo de instalarlo globalmente en primer lugar. No sería una gran solución si no pudiera resolver el caso de uso original, ¿verdad?

    Bueno, no te preocupes. Como dije, esta no es la respuesta completa. Hasta ahora, hemos resuelto el problema de las colisiones de versiones y hemos eliminado un paso y parte del mantenimiento de nuestros archivos README. Antes de llegar a la mejor solución, necesitamos saber un hecho importante: cuando instala localmente un paquete que tiene archivos "binarios" (es decir, es ejecutable desde la línea de comandos), se almacenarán los archivos binarios necesarios para ejecutar esa herramienta. en ./node_modules/.bin. Esto significa que puede utilizar ./node_modules/.bin/browserifypara ejecutar una versión instalada localmente de Browserify. Por supuesto, nadie quiere escribir todas esas tonterías, pero es un comienzo. Autoclave de vapor Blog

    Una solución rápida sería agregar ./node_modules/.bina su variable de entorno PATH para que pueda ejecutarla browserifyy que funcione. Al principio, me quedé anonadado cuando me informaron que podías usar rutas relativas como esa en tu RUTA (gracias a un comentario en otra publicación que escribí ), pero desde entonces mis emociones se han estabilizado porque me di cuenta de que esto solo funciona cuando están en el directorio raíz de su proyecto. La mejor solución que pude encontrar es incluir algunas entradas más en su RUTA para que pueda hacer esto también desde subdirectorios ( ../node_modules/.bin/y ../../node_modules/.bin/así sucesivamente, para tantos niveles de profundidad como considere necesarios); entonces, siempre debería poder encontrar el contenedor que estás buscando. Tenga en cuenta que el uso de PATH relativas tiene riesgos de seguridad, así que utilícelo solo en sus máquinas de desarrollo.

    Cambiar su RUTA en su propia máquina es excelente porque le ahorra pulsaciones de teclas, pero no creo que decirle a las personas que usan su proyecto que necesitan modificar su RUTA sea una gran idea. Una solución final requiere un poco de configuración para cada proyecto, pero puede ser muy útil más adelante, especialmente para otros usuarios de su proyecto: scripts npm . En su package.jsonarchivo, puede especificar una scriptspropiedad que esencialmente crea alias para sus comandos que npm puede ejecutar. Digamos que tu package.jsonaspecto es el siguiente:

     

    { … "scripts": { "browserify": "browserify" } …}

    Podrías ejecutar npm run browserifyy ejecutará la versión de Browserify que has instalado localmente en este proyecto. La clave de la propiedad es el alias que está creando para usar npm run(por ejemplo, npm run $KEY) y el valor es el comando que realmente se ejecutará. Cuando haga esto, npm buscará primero el browserifybinario en la ./node_modules/.bin/carpeta antes de verificar el resto de las carpetas en su RUTA.

    Por supuesto, tener que escribir npm run browserifyen lugar de simplemente browserifyno es tan eficiente, pero normalmente no uso scripts npm como ese. En cambio, lo configuré para que nadie necesite saber que uso Browserify, creando un alias genérico y dejándolo envolver un comando mucho más grande. Por ejemplo:

    { … "scripts": { "build": "browserify main.js bundle.js" } …}

    Ahora puedo ejecutar npm run build, lo que les permite a todos saber que están construyendo el proyecto, sin decirles los detalles esenciales de cómo se construyó, y de hecho estoy guardando las pulsaciones de teclas. La encapsulación le permite cambiar completamente las herramientas y la configuración de su compilación (haciendo el cambio a webpack , por ejemplo), sin tener que decírselo a nadie ni tener que actualizar la documentación.

    Los scripts de npm también le permiten pasar otras opciones al comando que está ejecutando, pasando primero --para decirle a npm que el resto de los parámetros se deben pasar al comando que se está ejecutando, en lugar de pasarlos directamente a npm run. Por ejemplo, usando el buildscript que acabo de crear, podemos ejecutar npm run build -- --debug, lo que sería el equivalente a ejecutar browserify main.js gt; bundle.js --debug.

    Los scripts npm son herramientas muy útiles para hacer que las tareas comunes sean fáciles de encontrar y ejecutar y para brindar a otros usuarios un acceso realmente simple a ellas. Incluso podrías hacer todo lo posible y aprender a usar npm como tu “herramienta de compilación” , que se está volviendo más popular. Pongo “herramienta de compilación” entre comillas porque, técnicamente, todo lo que hace es crear alias de comandos para su proyecto, pero la gente todavía tiende a llamarla su herramienta de compilación.

    Aumentar su PATH y/o utilizar scripts npm puede requerir un poco más de trabajo inicial que simplemente instalar la herramienta globalmente, pero realmente creo que es una mejor práctica y nos evitará algunos problemas de mantenimiento y compatibilidad a largo plazo, lo cual es Definitivamente algo bueno. Y no puede equivocarse al facilitar las cosas a los consumidores de sus proyectos.

    ¿Podemos o deberíamos llevar esto más lejos?

    Cuando llegas al grano, te das cuenta de que Node.js y npm también son dependencias de tu proyecto que pueden causar conflictos de versiones. Por lo tanto, deberíamos comenzar a enumerarlos también como dependencias, de alguna manera, para asegurarnos de que todos puedan trabajar con nuestros proyectos sin temor a conflictos.

    Para hacer esto, es posible instalar copias portátiles o locales de Node.js y npm en su proyecto. Esto tiene sus propias advertencias. porque no desea almacenar una instalación de Node.js en su control de versiones, e incluso si lo hiciera, esa instalación de Node.js probablemente no funcionaría en una computadora diferente porque sería específica del sistema operativo.

    Además, esto requeriría que ajuste su RUTA para usar Node.js y npm locales, y sus usuarios también deberán hacerlo. Estas no me parecen muy buenas compensaciones, por lo que, en mi opinión, no hemos llegado al punto en el que esto sea lo suficientemente sencillo de hacer. Tal vez surjan algunas herramientas en el futuro para permitir esto, pero tendremos que dejar esta idea a un lado por ahora.

    Conclusión

    Eso es todo lo que tengo para ti hoy. Espero que vea la importancia de mantener todas sus dependencias enumeradas y versionadas en su proyecto. Si está de acuerdo conmigo, ayude a promover esta idea señalándola cada vez que vea un proyecto que no siga este principio. ¡Pero recuerda ser amable! De hecho, incluso podrías considerar agregar una solicitud de extracción para realizar el cambio en el proyecto en cuestión.

    Imagen del extracto: npmjs.com

    Otras lecturas

    • “ Una introducción detallada a Webpack ”, Joseph Zimmerman
    • “ Precarga con Webpack ”, Anselm Hannemann
    • " Cómo aprovechar las máquinas: ser productivo con los ejecutores de tareas ", Adam Simpson
    • " React Native para Web: un vistazo al futuro ", Clayton Anderson

    (rb, al, ml, jb, nl, mrn)Explora más en

    • Codificación
    • Flujo de trabajo
    • javascript
    • Nodo.js





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    El problema con los paquetes de nodos globales

    El problema con los paquetes de nodos globales

    Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Friedman Implemente rápidamente. Implementar inteligentemente Índice

    programar

    es

    https://aprendeprogramando.es/static/images/programar-el-problema-con-los-paquetes-de-nodos-globales-881-0.jpg

    2024-05-20

     

    El problema con los paquetes de nodos globales
    El problema con los paquetes de nodos globales

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20