Prácticamente es imposible programar hoy en día en Javascript (sea en cliente o en servidor sin hacer uso del gestor de paquetes NPM. Tras la caída en desuso de Bower, NPM se ha convertido en el gestor de paquete JS por excelencia. Este gestor de paquetes, por defecto, está pensado para gestionar paquetes públicos que se ponen a disposición de la comunidad, pero también permite la utilización de forma privada dentro de nuestra organización.
Seguramente algunos han explorado la posibilidad de utilizar git+ssh
para poder utilizar nuestros repositorios privados desde NPM y de esta forma poder gestionar las dependencias. Aunque funciona, lo cierto es que da bastantes quebraderos de cabeza, sobre todo con servicios GIT privados y las credenciales.
También existe la posibilidad de utilizar npm link
cargar un paquete que está en nuestro disco. Es una alternativa, pero se complica de forma muy significativa en cuanto tenemos bastantes paquetes privados y, en general, no es una buena recomendación.
Existen varias alternativas para utilizar NPM de forma privada, que van desde:
- comprar una suscripción a la gestión privada de paquetes del propio NPM
- contratar un servicio NPM alternativo como Gemfury
- instalar nuestro propio servicio con Sinopa (discontinuado) o Verdaccio.
Personalmente hemos optado por este último y, en otro artículo, contaremos como instalar Verdaccio y sacarle todo partido.
Sea cual sea la opción que seleccionemos para disponer de nuestro NPM privado, lo cierto es que la gestión de nuestra reutilización de código por medio de paquetes es muy útil y nos permite aprovechar todas las posibilidades de reutilización, manteniendo el control de aquellas piezas de código que, por el motivo que fuera, no queremos o no podemos poner a disposición de la comunidad.
Pero ¿qué ventajas tiene utilizar un sistema de paquete en vez de simplemente utilizar nuestro repositorio como fuente de nuestro código reutilizable?
1.- Disponer de un sistema de paquetes privado permite gestionar de forma eficiente la reutilización del código. Permite buscar y encontrar las piezas de software que necesitamos en nuestro nuevo proyecto con rapidez. No es necesario ir buscando entre decenas o cientos de repositorios lo que estamos buscando, podemos utilizar el buscado de paquetes que nos ofrecen las diferentes soluciones para localizar lo que necesitamos.
2.- Vamos a poder instalar nuestros paquetes privados con rapidez en cada uno de nuestros proyectos, manteniendo todo bien organizado. Una vez localizado, es muy sencillo instalar este módulo o librería por medio del gestor de paquetes y un simple npm install nombre-paquete
. Nos va a traer todo el código que necesitamos y lo va a ubicar en la conocida carpeta node_modules
al que ya estamos acostumbrados todos. Lo interesante es que ahora el código que se incluye ahí combina paquetes públicos y privados.
3.- Cómo con los paquetes públicos, vamos a poder gestionar las dependencias con precisión y agilidad, pudiendo realizar las instalaciones y actualizaciones de forma ordenada, pudiendo desplegar el proyecto e instalar las dependencias sin que tengamos que llevarnos todo dentro de nuestro proyecto y aprovechando al máximo la gestión de versiones de estos paquetes para su actualización.
4.- Una ventaja interesante es que permite desplegar el código con mayor confianza, ya que tenemos mayor control también sobre las dependencias públicas. Un efecto curioso que tienen estos servicios NPM privados es que puedes sobreescribir un paquete público y cargar tu versión de este. Esto es especialmente útil en caso de detectar problemas o vulnerabilidades en dependencias subordinadas de los paquetes que utilizamos en nuestros proyectos. Si un paquete que utilizamos tiene él un problema podemos forzar la versión, pero si el problema está más profundo en la cadena de dependencias, tenemos bastante difícil poder corregir este problema. En estos casos podemos parchear el módulo en cuestión y asegurarnos que sólo vamos a cargar nuestra versión modificada.
5.- Utilizar un NPM privado fomenta el uso de nuestros paquetes corporativos. Aunque tengamos un buen repositorio GIT y tengamos la documentación a mano, lo cierto es que utilizar un gestor de paquetes que todos conocemos facilita mucho la vida y, como consecuencia, se extiende con mayor rapidez la utilización de nuestras librerías y módulos en la organización.
Para sacarle todo el partido a nuestro NPM privado nos atrevemos a dar algunas pequeñas recomendaciones sobre la base de nuestra experiencia con este tipo de sistemas:
1.- Utilizar antes de reutilizar. Uno de los efectos colaterales que tiene este tipo de planteamientos es que podemos llegarnos a obsesionarnos en cierta medida con la reutilización y todo lo que empecemos nos planteemos con intensidad cómo podemos hacerlo reutilizable. Nuestra experiencia nos ha demostrado que es mejor relajarse y empezar utilizando las cosas en los proyectos, y luego ponerse en modo bibliotecario y ver que podemos reutilizar de lo que ya estamos utilizando.
2.- Versionar adecuadamente. Es posible que en nuestros proyectos no hayamos dado mucha importancia a la versión que aparece dentro del fichero package.json
. Cuando trabajamos con NPM esta versión es muy importante, ya que, por una parte, no nos va a permitir publicar una actualización sin cambiar esta versión, y por otra, va a utilizar esta versión para realizar las actualizaciones. Tenemos que entender y utilizar el versionado semántico (https://docs.npmjs.com/getting-started/semantic-versioning).
3.- Utiliza una buena descripción y documenta los paquetes en un fichero README . El resto de los compañeros lo va a agradecer. Para localizar el paquete la descripción del fichero package.json
es importante. Para comprender el funcionamiento del paquete el fichero README.md
debe describirnos todo lo que necesitamos para utilizar nuestro paquete, que tenemos que hacer para sacarle el máximo partido y que cosas tenemos que tener en cuenta para no cometer errores en su uso.
4.- Pon algunos buenos ejemplos de uso. Reconozcámoslo, la mayoría de nosotros cuando nos enfrentamos a un nuevo paquete lo primero que hacemos es buscar algún ejemplo sencillo que podamos copiar en nuestro proyecto para empezar a utilizarlo sin necesidad de leernos cientos de líneas de explicación. En nuestros paquetes privados es muy conveniente poner ejemplos sencillos para que otros compañeros puedan utilizarlos como esquema base sobre el que empezar a desarrollar su código.
5.- No subas absolutamente todo al paquete, ya está en el repositorio, pon en el paquete lo que sea realmente práctico distribuir. Piensa en publicación del paquete en los servidores de producción, no sólo en los compañeros de desarrollo. El fichero .npmignore
es muy útil y en él podemos indicar que parte de nuestro proyecto se ignorará en la publicación del paquete. Por ejemplo, nosotros en los paquetes no incluimos los juegos de pruebas, estos ya están en el repositorio GIT, ocupan bastante espacio y no son necesarios para la utilización del paquete, aunque si los dejas tampoco es un problema.
6.- Utiliza un prefijo para tus paquetes privados, de esta forma evitarás confusiones con los paquetes públicos. Es muy sencillo, simplemente pon el nombre de tu empresa, un guion y el nombre del paquete, por ejemplo corus-httpServer
o kubide-secureService
. De esta forma se evitan conflictos entre tus paquetes privados y aquellos públicos que utilicen el mismo nombre que los tuyos.
7.- No parchees los paquetes públicos, si puedes evitarlo. Mejor haz una contribución al paquete con la corrección, pero si no te hacen caso o tardan en publicarlo, siempre tienes como alternativa el poder hacer tu versión del paquete y mantener las dependencias intactas, cargando tu versión modificada.
En definitiva, utilizar un servicio de NPM privado, ya sea en la nube o instalado por ti, va a facilitar la reutilización ordenada de código dentro de tu organización, por lo que te animamos a que explores sus posibilidades y compartas con la comunidad tu experiencia.
Novedades
HTTP2 para programadores. Enviar mensajes del servidor al cliente con Server Sent Event (sin WebSockets)
En esta charla, organizada por MadridJS, Pablo Almunia nos muestra cómo la mayoría de nosotros cuando oímos hablar por primera vez de HTTP2 nos ilusionamos con las posibilidades que presumiblemente se abrían para el desarrollo de soluciones web avanzadas y cómo muchos nos sentimos defraudados con lo que realmente se podía implementar.
En esta charla podemos ver cómo funciona el HTTP2, que debemos tener en cuenta en el servidor para hace uso de este protocolo y, sobre todo, cómo podemos enviar información desde el servidor al cliente de forma efectiva y fácil. Veremos con detenimiento cómo por medio de los Server-Sent Events (SSE) podemos recibir en el cliente datos enviados desde el servidor sin utilizar websocket, simplificando enormemente la construcción de aplicaciones con comunicación bidireccional.
Observables en Javascript con Proxies
En esta charla, organizada por MadridJS, Pablo Almunia nos habla de la observación reactiva de objetos en Javascript por medio de Proxy. Se describe paso a paso cómo funcionan los Proxies y en que casos pueden ser nuestro mejor aliado. Veremos que no hay que tenerles miedo, son bastante sencillos de utilizar, y nos ofrecen una gran abanico de posibilidades.
Aplicaciones JAMStack, SEO friendly y escalables con NextJS
En esta charla de Madrid JS, Rafael Ventura nos describe las funcionalidades clave de NextJS, nos muestra en vivo cómo desarrollar una completa aplicación JAMStack con Server Side Rendering (SSR) y Static Site Generation (SSG) y termina mostrando como publicar esta aplicación en Vercel.
Stencil JS: mejora el Time To Market de tu producto, por Rubén Aguilera
En esta charla Rubén Aguilera nos cuenta los problemas que tienen muchas empresas a la hora de sacar productos accesibles, vistosos y usables en el Time To Market que requiere Negocio y cómo podemos minimizar este tiempo gracias al DevUI con StencilJS para adecuar una aplicación de Angular a las exigencias del mercado en tiempo record.
Cordial saludo,
Como puedo publicar un paquete que tenga el prefijo @nombre/paquete