Cinco formas de aprovechar Verdaccio, tu registro privado y proxy de Node.js

de aprovechar Verdash como un registro privado y proxy de Node.js. Así que, comencemos.

En primer lugar, algo sobre mí. Mi nombre es Juan Picado. Soy ingeniero senior de frontend en Mobility Dare, que es una marca de Ativinta. Estoy basado en Berlín. También dedico parte de mi tiempo a trabajar en proyectos de código abierto, principalmente manteniendo el proyecto Verdash. Así que, si no lo conoces, lo conocerás más en los próximos 20 minutos y espero que te guste. Así que, empecemos. Somos desarrolladores de Node.js y también desarrolladores de JavaScript. Así que puedo imaginar que ya has publicado un paquete y aún no has hecho esto. Entonces, disfrutarás de esta charla porque es muy, muy sencillo hacerlo localmente. Verdash es un registro privado y proxy de Node.js ligero, que es completamente opcional en su configuración, y te permite alojar y publicar paquetes privados de Node.js. Y es compatible con cualquier gestor de paquetes. Este diagrama describe un viaje sencillo de una solicitud donde el registro privado siempre está en el medio entre el remoto, que puede ser uno o más, y luego tienes una caché local. Y esta caché local realmente tiene beneficios. Quiero mostrarte cómo usarla en tu proyecto. Así que, en primer lugar, necesitas instalar Verdash. Y para eso, necesitas instalar el paquete globalmente. Y eso es todo. Así de simple, no necesitas hacer nada más, solo comenzar. Luego, lo siguiente que debes hacer es ejecutar el comando Verdash. Sí, eso es todo. Así que, tendrás un registro que se está ejecutando con una interfaz de usuario para navegar, no solo por paquetes privados, sino también por dependencias, incluso si son públicas. Porque Verdash, no carga ninguna solicitud de paquete a través del gestor de paquetes o la interfaz de usuario. Para ayudarte a comprender he preparado cinco formas básicas y cómo Verdash puede ser realmente útil para cualquier desarrollador de JavaScript.

hoy en día. Así que, comencemos con el primero. Lo cual es desarrollo personal. Así que, vamos a publicar un paquete. Para este ejemplo, tengo un npm Workspaces, que es bastante simple y lo veremos ahora. Y la idea es publicar algunos paquetes. Así que, primero déjame mostrarte la estructura del proyecto, que no es mucho. Solo 5 módulos. Y uno de ellos, esta es la configuración para npm Workspaces, y uno de ellos hace referencia a otros en su interior. Veremos por qué hago esto cuando publiquemos y te lo mostraré en la misma. Así que lo primero que tienes que hacer es ejecutar Verdash. Y si quieres publicar necesitas iniciar sesión. Para eso, puedes usar el comando login. Y si quieres apuntar a otro registro, entonces usa la bandera registry y la URL del registro. En este caso, localhost 4873, que es el puerto predeterminado de Verdash. Inicias sesión y luego si no tienes ningún usuario simplemente usa lo que quieras. La contraseña y el correo electrónico no son importantes porque Verdash no los utiliza. Y luego estás conectado. Puedes ver que el servidor reacciona a cualquier comando que escribas. Esto se debe a que el gestor de paquetes está conectado con la API del registro. Así que ahora vamos a publicar un paquete. Y si has usado Workspaces en npm puedes publicar varios paquetes al mismo tiempo usando simplemente estos slack workspaces. Y esto es lo que vamos a hacer y simplemente sucede. Sí, lo hicimos. Así que tenemos paquetes en el registro. Así que veamos cómo se ven estos paquetes en el registro. Y esta es la interfaz de usuario. Puedes cambiar al modo oscuro. Y aquí tenemos los cinco paquetes. Genial. Y estas son las dependencias que te mostré antes. Así que simplemente puedes navegar a través de ellas y

ver quién tiene las dependencias de quién. Y eso es todo. Así de simple. Acabo de publicar un paquete en solo unos segundos. Sí, pero hay una restricción que debes tener en cuenta. Si publicas un paquete, un paquete privado, cuya versión no existe en ninguno de los upstreams, que también llamamos Applinks, como VAC17 por ejemplo, si ya existe en el registro, Verdash siempre buscará esta versión y si ya existe y si la condición es verdadera, recibirás un error 409. Esto es bastante común si quieres parchear una versión pública, ¿verdad? Para evitar esto, simplemente puedes agregar un sufijo a la versión. Y tu versión no se perderá una vez que Verdash actualice nuevas versiones porque Verdash fusiona lo que tienes localmente con lo que tienes de los upstreams. Así que hagamos una demostración rápida también para mostrarte los beneficios y cómo podemos resolver esto con este paquete react. Veamos si encuentro el proyecto... Ah, aquí está. Aquí podemos ver esta versión, es la actual en npmjs. Ejecutemos Verdash nuevamente. Ya hemos iniciado sesión, así que no necesitamos iniciar sesión nuevamente. Y tratemos de publicar esta versión con la bandera registry. ¡Boom! ¡Sí! Conflicto de publicación. Para resolver esto puedes cambiar la versión manualmente, pero es mucho más fácil si usas una versión de parche. Y en este caso estoy usando la versión no de GitHub porque acabo de clonar este proyecto, no quiero crear una etiqueta local en mi proyecto. Así que simplemente ejecuto esta versión y cambiará automáticamente. Puedo ejecutarlo varias veces y puedes ver cómo la versión cambió según la anterior. Y ahora publiquemos este paquete. Simplemente publica y ahí está, así que si volvemos al registro nuevamente podemos ver si lo encuentro, podemos ver que la última versión es la que acabo de publicar. Si accedo a la versión de React podemos navegar a través de las versiones, por lo que puedo ver las que vienen de fuera más la que acabo de publicar. Así que continuemos con la siguiente diapositiva. Publicar es fácil, pero si estás trabajando en un entorno sin conexión como yo en este video trabajando en un avión, lo cual es bastante común si estás viajando o vives en áreas remotas o no hay conexión en absoluto. Si quieres publicar paquetes, y esta es la razón por la que existe Verdash, porque puedes publicar paquetes en cualquier lugar, entonces necesitas habilitar la publicación sin conexión en la configuración. Esto no está habilitado de forma predeterminada porque las razones son porque el registro siempre busca versiones en remotos. Si no hay conexión, la publicación fallará. Además, puedes mejorar la experiencia sin conexión eliminando la propiedad proxy en la configuración

archivo. Puedes verlo en la diapositiva. Verás más sobre esto en las próximas diapositivas. Hay una razón para eso. A continuación, se encuentra la productividad del proyecto e integración continua en registros privados. La mayoría de los paquetes públicos que utilizamos en la actualidad se publican a través del registro privado, pero también se llaman desde otros registros. Todos estos registros son servicios que requieren alta disponibilidad, pero esto no es 100% del tiempo, porque ocurren interrupciones públicas y debes estar preparado para ello. En esas situaciones es cuando las capacidades de los registros privados y los proxies son fundamentales para tu canal de desarrollo. Porque tener un registro proxy entre tu canal y tus servicios públicos evitará que tus equipos o tus compilaciones dejen de funcionar mientras ocurre una interrupción. Verdash tendrá esta capacidad de forma predeterminada, almacenará en caché cualquier dependencia y versión según la demanda, por lo que la próxima vez que se solicite, se servirá la que está en caché. Porque en el entorno de integración continua, las compilaciones se ejecutarán varias veces en la misma solicitud de extracción cuando envíes cambios a tu repositorio, lo que implica que el manifiesto del paquete para un paquete público se descargará una y otra vez. Verdash tiene un caché predeterminado de 2 minutos, pero puedes aumentar el caché simplemente indicando al registro que no necesitas una nueva versión cada 2 minutos, tal vez 10 minutos esté bien para ti. Esta es una práctica realmente buena porque acelerarás tus compilaciones, ya que el registro no necesitará hacer solicitudes externas para preguntar si tienes cambios nuevos. Además, si la red no funciona correctamente, también puedes aumentar el número máximo de fallas en la configuración. Todas estas configuraciones se basan en un enfoque del lado del cliente con intervalos amigables como 2 semanas, 3 semanas, 30 segundos y así sucesivamente. Esto hace que sea mucho más fácil para los desarrolladores entender qué es realmente

los valores que has configurado. Y el tercer tema es seguridad porque la seguridad es un tema que debe abordarse desde 2 ángulos. Primero, desde el lado del cliente porque necesitas utilizar las configuraciones correctas en el Gestor de Paquetes. Puedes obtener más información sobre esto en el sitio web virtual. También tengo un enlace en las 2 diapositivas siguientes. Pero también desde el lado del servidor porque se plantea por sí mismo y voy a explicarlo un poco más ahora porque hay una razón. Y si no recuerdas lo que sucedió hace 1 año, déjame recordártelo rápidamente. Un investigador de seguridad descubrió que una configuración incorrecta en los registros podría permitir que los paquetes privados sean reemplazados por paquetes maliciosos, que se publican en registros públicos con el mismo nombre. Esto podría comprometer la seguridad. Esta historia es demasiado larga, pero aquí te dejo un buen artículo donde puedes leer más al respecto . Esto es solo un recordatorio de que un registro es una gran ventaja y te brinda una capa adicional de seguridad. Pero también es una gran responsabilidad porque debe configurarse correctamente. Aquí hay dos consejos prácticos. Primero, aísla tus paquetes privados utilizando ámbitos. Por lo general, es el nombre de tu empresa, de tu proyecto o de tu organización. Y también intenta registrar este nombre en registros públicos. Porque esta es una forma de tener un control total. En caso de que no hayas configurado correctamente el registro localmente, al menos tienes el control del ámbito externo. La segunda razón es, especialmente si estás utilizando Verdacho, por favor elimina el proxy en la configuración para evitar que el registro obtenga fuentes externas para actualizaciones. Esto es muy recomendable para los paquetes de ámbito. Si tienes la intención de que sean privados, especialmente si

si estás utilizando Verdacho. Por lo tanto, las últimas versiones de Verdacho incluyen una nueva función de seguridad, que es el límite de velocidad. En este punto, puedes agregar el límite de velocidad a dos áreas, que son los puntos finales web, los puntos finales de seguridad, que son el inicio de sesión y el cambio de contraseña. Con eso, vas a utilizar la posibilidad de un ataque de denegación de servicio, que son puntos clave en. Por defecto, están configurados con un número muy bajo de solicitudes, pero esto se puede cambiar. Por lo tanto, recomiendo totalmente utilizar esta función si aún no te has dado cuenta de que existe. Las pruebas de extremo a extremo, que son mis favoritas, garantizan la integridad de tus paquetes cuando publicas un paquete y la estructura y funcionalidad de estos modelos no se ven afectadas cuando los usuarios los consumen. Hay muchas formas de romper un paquete, la más común es la configuración incorrecta, porque no importa cuán bien probado esté tu modelo. Hay algunos pasos principales cuando estás configurando para enviar un paquete que dependen de los desarrolladores, y podría ser que olvidaste agregar el campo principal si estás intentando enviar un paquete de CommonJS, o tal vez olvidaste el módulo si estás intentando usar un módulo JSON, o tal vez olvidaste los patrones correctos en la propiedad de archivo en el paquete. Además, es posible que hayas configurado incorrectamente el archivo .npm.ignore en el archivo raíz. Hay muchas cosas involucradas en el envío de un paquete, y cualquier error cuenta y solo se puede detectar al publicar. Para eso, necesitas un registro. No puedes publicar instantáneas todo el tiempo en el público, especialmente si tienes paquetes privados, por lo que recomiendo probar la publicación de tus paquetes en cada solicitud de extracción, al igual que un storybook lo hace en esta diapositiva, por ejemplo. Veamos un ejemplo, puedo romper un paquete que está destinado a ser enviado como una interfaz de línea de comandos. Aquí tengo una demostración, si quieres verla más tarde, simplemente imprime `Hola mundo` en la consola y utiliza GitHub Actions, Docker y Node.js para ejecutar pequeñas pruebas de extremo a extremo. Entonces, como puedes observar, esta es una vista de mi proyecto de GitHub, donde mis pruebas están rotas en la rama principal. Entonces, veamos rápidamente cuál es la razón y solucionémoslo en un momento. Este es mi proyecto y, si te fijas, hay algo incorrecto en la configuración, en el paquete. Veamos por un momento qué podría ser, y parece que es el archivo bin. Este archivo no existe en la raíz, no existe. Entonces, ¿qué podemos hacer para solucionarlo? Bueno, simplemente usar el nombre correcto, ¿verdad? Y, en realidad, vamos a confirmar este archivo porque si... y esto debería solucionar el problema. Entonces, vamos a confirmar esto. No, no quiero romper la rama principal, quiero solucionarla. Sí, vamos a enviar estos cambios y mientras GitHub ejecuta la acción, te mostraré cómo estoy haciendo esta prueba. Entonces, si no estás familiarizado con GitHub Actions, es muy sencillo, te recomendaría totalmente que los uses. Aquí tenemos el servicio. El servicio es una propiedad que te permite usar imágenes de Docker dentro de tu acción. En este caso, estoy usando la imagen de Docker de Verdacio, que es la oficial. Estoy exponiendo un puerto, es decir, el mismo. Para el S73, con esto puedes

utiliza el registro en todos los pasos a continuación. Entonces, primero solo inicio sesión porque sí, necesitas iniciar sesión la primera vez. Luego publico el paquete. Esto es lo que cualquier usuario hará. Luego, solo verifico si el paquete está allí, lo cual es opcional. Luego, instalo globalmente el paquete. Cuando instalas globalmente un paquete OGS usando VeeN, este comando estará disponible en el contexto global. Y luego ejecuto la prueba. En la prueba no tengo nada especial, solo estoy usando un proceso relajado, que utiliza SpanSync. Ejecutando el comando, se supone que estará disponible en el contexto global. Este será el primer punto de interrupción si no hay comando. Esta prueba fallará. Luego tomará el resultado. Y luego comparamos el resultado, si está bien, todo está bien. De lo contrario, proceso x con uno, lo que significa que GitHub fallará. Vamos a la acción de GitHub. Sí, hace dos minutos. El maestro arreglado funciona perfectamente. Si vemos la acción interna, podemos ver que esto pasó correctamente. Perfecto. Y el maestro está nuevamente en verde. Muy bien.

Así que volvamos a las diapositivas. Hay muchos ejemplos de código abierto, y la mejor manera de aprender es un buen ejemplo es leer código abierto. Por ejemplo, puedes usar Angular CLI, que también utiliza Chill para ejecutar Verdacho. En este caso, están utilizando Verdacho programáticamente para ejecutar el registro, y esta también es una buena manera de hacerlo. Así que si quieres más ejemplos, solo envíame un mensaje en el chat y puedo darte más, porque tengo muchos más para compartir.

Um, porque tener tu propio registro puede ser intimidante. ¿Qué tan difícil es alojar un registro? ¿Cuánto cuesta? ¿Cuánto esfuerzo? Todas estas preguntas son comunes, y un registro necesita dos piezas fundamentales, el servidor y la interfaz de usuario, y Verdacho tiene ambos en el mismo paquete. Además, debes preguntarte qué esperas de un registro. Porque Verdacho se adapta mejor si buscas privacidad, flexibilidad, personalización, entornos sin conexión y en general, bajo costo. Porque eso es lo que estamos haciendo en la organización de Verdacho, estamos utilizando nuestro propio registro y nuestras compilaciones. Hemos estado ejecutando nuestro propio registro durante tres años, lo que cuesta alrededor de $60 al año. Y tenemos miles de compilaciones cada mes, incluyendo todas las dependencias de todas las personas que contribuyen, lo que supone muchas solicitudes al registro todos los días. Y hasta ahora no hemos necesitado escalar porque ha estado funcionando muy bien con la configuración predeterminada. Pero esta es nuestra propia configuración personal. Es posible que tengas requisitos diferentes, y Verdacho es flexible. Es posible que necesites un almacenamiento diferente. Por ejemplo, puedes usar S3 en Amazon Web Services o tu propio Cloud como Minio. Es posible que necesites tu propio proveedor de autenticación o tal vez cambiar por completo la interfaz. Verdacho también permite middleware porque utiliza Express en este punto. Este es un ejemplo. Estoy utilizando MPM Audit. Estamos aplicando plugins que brindan soporte a este comando. Así que es posible que desees ampliar tu propio registro. Pero sí, esto también puede incluir desarrollo personal, creando tus propios plugins. Así que eso es todo por mi parte. Muchas gracias por escuchar mi charla. Verdacho es un registro de código abierto hecho para desarrolladores y hecho para colaboradores, lo que hace de este proyecto una gran alternativa. Y en nombre de todos los colaboradores, gracias por ver mi charla. Y espero que te guste y aprendas algo hoy. No dudes en hacer más preguntas o contribuir al código abierto. Así que muchas gracias. Adiós.

Echando un vistazo a los resultados de la encuesta, ¿qué opinas? Así que un tercio de todos los asistentes, bueno, les preocupa alojar un registro, pero también hay muchas respuestas interesantes como la seguridad. ¿Qué opinas al respecto? De hecho, he revisado los resultados y coincide con mis expectativas. Por lo general, el nombre de la descripción del proyecto indica que se puede alojar un registro. Este es el caso de uso más común. Pero también tiene otros, como mencioné en el libro. Y Antoine testing es una tendencia que se está volviendo popular. Viste en la presentación que mencioné algunos proyectos, pero veo muchos, muchos proyectos que tienen monorepos y les preocupa lo que están enviando. Antoine testing es algo importante. La seguridad, sí. El año pasado fue un año importante para los registros y la seguridad. Y el proyecto fue bifurcado por otro, que estaba más destinado al desarrollo personal. Esto es quizás lo menos conocido. Puedes usar un registro en tu computadora. Y lo que me sorprende es la integración continua, porque como mencioné, en una de las diapositivas generalmente no se usa. Confiamos mucho en los servicios y esto es peligroso. Así que sí, eso es genial. Gracias. Bueno, tenemos algunas preguntas, si no te importa. En primer lugar, esta es mi pregunta también, y creo que está en la mente de muchas personas. ¿Cuál es la mejor manera de contribuir a Verdacho? ¿Cuál es la mejor forma de involucrarse? Bueno, simplemente tener la voluntad de aprender. Esa es la más importante. Así es como empecé en Verdacho. Sí, quiero aprender Node.js y en el repositorio tenemos varias formas en las que puedes ayudar. Primero, si eres principiante, puedes empezar corrigiendo tipos que estamos migrando. Tenemos nuestra hoja de ruta en el repositorio, que es muy sencilla, y puedes encontrarla fácilmente en los problemas y las discusiones. Y hay una descripción de lo que puedes hacer. Ya sea que seas un desarrollador de Node.js puro y quieras aprender algo o mejorar el código, tienes los pasos de cómo hacerlo. Si te gusta más el front-end, tenemos una interfaz de usuario basada en React y Material UI, que también necesita ayuda. Y sí, puedes tener buenas características. Y si no

Si eres un programador, tal vez quieras ayudar con las traducciones. También puedes ayudar a traducir el software a varios idiomas. Ya tenemos alrededor de 15 idiomas en la interfaz de usuario y también en ladocumentación. Y sí, también puedes ir al chat y ayudar a otros a usar Bellagio. Esa es otra forma. Muchas gracias. Eso es genial. Otra pregunta es, ¿se puede usar Verdacio como proxy para no solo uno, sino varios registros? Sí. Cuando estás usando Verdacio por primera vez e instalas paquetes a través de él, los paquetes no llegan mágicamente. Vienen del registro público, pero puedes usar varios. Quiero decir, imagina que tienes otro registro en tu empresa y quieres obtener los paquetes de allí y también del registro público. Así que puedes configurar uno o más. No hay límite. Quiero decir, creo que el límite es el cielo o, en este caso, tu hardware. Y si es privado, puedes usar credenciales para acceder a él. En tu empresa puedes configurar credenciales y acceder a varios registros. Esta es una de las características que no es muy conocida. Puedes definir un paquete específico, por ejemplo, React. Imaginemos. Y puedes buscar React en tu registro privado. Y puedes definir una regla, como, si no existe en el privado, entonces lo buscaré en el otro. Y puedes crear esta combinación, que es realmente agradable. Y sí, es totalmente, totalmente posible. Eso es realmente agradable. Bueno, otra pregunta que tenía es que estoy seguro de que otros pueden estar familiarizados con otras iniciativas para crear repositorios no-npm. Un ejemplo sería Entropec, que la gente podría conocer. ¿Cómo crees que Verdacio se compara o tal vez se diferencia de esos proyectos? ¿Cuál? ¿El Entropec que mencionaste? Sí, Entropec. ¿O tal vez hay otros proyectos de los que tienes conocimiento y que crees que son diferentes? No hay muchos en el código abierto, desafortunadamente. Me gustaría ver más. Pero la mayoría de esto, Entropec fue una idea que aún está abierta, pero parece que no ha tenido mucho desarrollo. Pero fue una idea para crear un registro, un registro distribuido. Sí, desafortunadamente no ha habido mucho desarrollo allí, pero la idea fue interesante.

Y aparte de eso, solo hay servicios. Hay algunas empresas que están creando registros, posibilidades de paquetes privados. Pero sí, quiero decir que tienes que pagar por ellos. Algunos tienen una prueba gratuita, que puedes usar. Pero la diferencia principal es que todavía son todos servicios, ¿verdad? Así que necesitas internet y básicamente, puedo decirte que la gente suele acercarse a mí para preguntarme cosas como `oh, vivo en esta área o vivo en este país, donde no se permite usar el servicio o lo que sea`. Y mi única forma de aprender Node.js es porque realmente puedo instalarlo en mi computadora y simplemente usarlo. Eso es interesante para mí. Sí, eso es realmente interesante. De hecho. Verdacho se puede utilizar como una herramienta contra los cortes de internet o eventos similares. Otra cosa. Así que cuando hablamos del caso del repositorio privado, creo que nos hemos centrado mucho en la confiabilidad y el almacenamiento en caché y demás. Pero por supuesto, hay otra forma de trabajar con un repositorio privado donde puedes tener un repositorio privado dentro de tu empresa donde hayas publicado exclusivamente tu código privado y luego puedes construir a partir de eso. ¿Verdacho permite esto? ¿Hay muchos usuarios de esto? ¿Qué piensas? ¿Te refieres a alojar un registro dentro de tu empresa? Sí, y alojar paquetes locales de código cerrado, para que no tengas que importarlos usando enlaces de Git y demás, y en su lugar puedas simplemente clonar en tu privado... Verdacho solo admite dependencias con versionado semántico, por lo que no... quiero decir no puedes descargar un repositorio de Git o algo así. Eso no funciona. Hay otras soluciones como en package.com, creo. Es como un registro pero es como un CDN. He recibido solicitudes de personas, pero eso no es lo que hace Verdacho. Sí, quiero decir que puedes tener tu registro dentro de tu empresa ya sea para almacenamiento en caché o para alojar tus privados, por ejemplo, como un sistema de design que no deseas publicar externamente y generalmente tienes este tipo de cosas que puedes usar en varios proyectos. Entonces necesitas el registro de alguna manera porque necesitas publicar paquetes allí. De acuerdo, eso fue genial, muchas gracias Juan. Fue un placer escuchar tu charla y fue aún más interesante interactuar contigo. Bueno, desafortunadamente se nos acabó el tiempo, pero si aún no has terminado de escuchar sobre Verdacho, puedes unirte al chat especial. Entonces, Juan, ¿estarás en el chat especial, verdad? Claro, estaré allí. De acuerdo, genial. Bueno, en ese caso puedes unirte allí y podemos pasar a la siguiente parte. Gracias. Fue muy agradable tenerte aquí. Muchas gracias. Muchas gracias por tenerme aquí.