Desenredando tus Dependencias: Un Patrón para un Proyecto de React Bien Tejido

Hola a todos. Muchas gracias por unirse a mi sesión sobre cómo desenredar sus dependencias. Este es un tema del que realmente disfruto hablar y siento que resuena con muchos de nosotros que tenemos que gestionar nuestras dependencias, especialmente en proyectos más grandes.

Solo para poner el escenario, vi un mensaje en el grupo de Slack de Freelancers de Viena que decía, Tengo un cliente buscando desarrolladores de React Native. Remoto, freelance, buena tarifa, podría terminar siendo una situación de retención. Y lo siento, siempre me río cuando leo esto porque siempre suena como ese audio de TikTok, ya sabes, el que dice, como, estoy buscando un hombre en finanzas. De todos modos. Así que dije que sí. Ser freelancer realmente me ha dado el poder de sentirme seguro para simplemente lanzarme y decir, bueno, nunca he hecho TypeScript, pero estoy seguro de que puedo. El proyecto también era React Native, TypeScript, y fue muy divertido trabajar con él. Y fue un desafío realmente interesante para mí.

Porque cuando entré, ese proyecto no se había trabajado en un tiempo. Tanto así, que cuando lo ejecuté, obtuve un error. Intenté ejecutar la versión de iOS y el error que obtuve fue, no se pudo encontrar el simulador de iPhone 6. Y aquí está la cosa, amigos, intenté 6 no es del año pasado, como siento en mi corazón. Lo es. Pero en realidad ha pasado más tiempo entre el iPhone 6 y ahora, que entre el iPhone original y el iPhone 6. Solo compartiendo un poco de mi dolor.

De todos modos, genial. Intenté, estaba tremendamente desactualizado. ¿Qué pasa con la compilación de Android? Intenté, intenté, si no estás familiarizado con React Native, te permite escribir aplicaciones para ambas plataformas móviles y también intenté plataformas como la web. Y sí, eso incluye iOS y Android. Así que de todos modos, ejecuté la compilación de Android, y obtuve algún error de Java. No estaba seguro de lo que significaba. Pero está bien. Pensé para mí mismo, sabes qué, solo voy a actualizar todo. Va a estar bien. Y bueno, intenté saber cómo fue eso. Así que primero, intenté, bueno, la versión de React Native en este proyecto es 55.4, y en el momento de grabar esto, de escribir esta presentación, React Native estaba en 074.1. Y así, simplemente lo actualicé de una vez.

Simplemente fui al archivo package.json y solo cambié ese número. NPM install, y listo. Y te puedes imaginar que obtuve un error. Algo sobre que React DOM no funcionaba bien. Y pensé, está bien, no hay problema, simplemente actualizaré React DOM. Y luego React se rompió. Y luego algunos otros paquetes se rompieron.

Y después de un tiempo de intentar arreglar esto, se sintió como una de esas cajas de cables. ¿Todos tienen estas en casa? Me gustaría escucharlo en el chat, por favor. Como, ¿tienen en su casa solo una caja llena de cables que realmente saben desesperadamente que necesitarán algún día? Y probablemente tengan personas en sus mensajes o lo que sea o sus amigos diciéndoles, tira esos cables. Déjenme decirles, no los tiren. Nunca saben cuándo van a necesitar ese cargador de Nokia 3310. Confíen en mí.

Así que de todos modos, trabajando a través de todo esto, traté de seguir con nuestra metáfora un poco más. Se sintió más como si estuviera trabajando con un ovillo de lana muy enredado al tratar de tejer un proyecto. Traté de, como ven, el dibujo en sí no hecho por mí, pero los garabatos un poco más hechos por mí. No soy muy buen artista. Así que de todos modos, eso es en lo que vamos a entrar hoy. La pregunta no es tanto, ¿cuáles son las mejores prácticas para gestionar dependencias? Soy un gran defensor de que las mejores prácticas cambian con el tiempo. En cambio, traté de hablar sobre cuáles son mis prácticas favoritas para gestionar dependencias. Y para hacer eso, voy a contarles un poco sobre mí.

Así que hola, mi nombre es Katmin, pronombres ella. Soy originaria de Chile, viviendo en Austria desde hace mucho tiempo. Trabajo como educadora de desarrolladores en una empresa llamada Directus. Y soy cofundadora del Bad Website Club donde mi amiga Jess y yo hacemos que la educación para desarrolladores sea más accesible y llevamos a la gente a la programación en un entorno de muy bajo estrés y bajo perfeccionismo, tanto como podemos. Intento realmente amar las comunidades. Siento que esta es una de las mejores maneras en que podemos aprender y crecer como seres humanos. Intento pensar en las dependencias, a veces las damos por sentadas, ¿no? Simplemente las lanzamos y decimos, sí, lo que sea. Necesito algo para, ya sabes, hacer mi vida un poco más fácil. Y realmente no voy a pensar en el código.

Pero al final del día, sigue siendo un fragmento de código que estás introduciendo en tu proyecto, ¿verdad? Así que lo intenté. La cosa es que, con el tiempo, esas dependencias se acumulan en tamaño. Probablemente hayas visto este meme antes. Los objetos más pesados del universo y tu carpeta de Node Modules es bastante pesada. Recuerdo que estaba en una conferencia y alguien dio una charla sobre cómo tomaron ese concepto de la carpeta de Node Modules e hicieron un juego de Katamari con él. Donde si no estás familiarizado, juegas como un pequeño personaje y ruedas una bola y a medida que recoges objetos más grandes, la esfera que estás rodando crece en tamaño. Y lo hicieron con una carpeta de Node Modules, lo cual me pareció hilarante.

Intenté trabajar con todas esas dependencias. Se siente un poco como un juego de equilibrio. Y no sé tú, pero a veces me pongo un poco nervioso de que si solo intento una parte que estoy moviendo, todo se va a colapsar. Un poco como un gran juego de Jenga. Lo intenté. Lo intenté. Voy a hacer esa parte donde traigo una cita de una persona realmente inteligente a la presentación. Y realmente me esforcé mucho para asegurarme de que esto no fuera una de esas situaciones de Mark Twain, ya sabes, donde se le atribuye a Mark Twain. Estoy bastante seguro de que fue Leonardo da Vinci quien dijo, el arte nunca se termina, solo se abandona. Y de alguna manera siento que eso se aplica al software también. Así que lo que voy a hacer es simplemente mostrarte un par de trucos y consejos para gestionar tus complejos sistemas de gestión de dependencias y cómo puedes entenderlos mejor. Intenté desde el principio, ¿no? Intenté hablar mucho sobre dependencias y, ya sabes, filosofamos sobre diferentes estilos de gestión. Pero, ¿qué hay de entender qué tipo de dependencias hay? Intenté. Intenté. Intenté. Intenté. Y vemos esto cuando trabajamos con, por ejemplo, un archivo package.json donde tenemos dependencias y dev dependencies. Ahora, admitiré que hubo un tiempo en que simplemente lanzaba todo en la misma caja. Estoy como, oh, ya sabes, estoy desarrollando un proyecto. Simplemente lo pondré en dev dependencies. Estará bien. Intenté amigos. Intenté que las dev dependencies no se incluyan en un paquete de producción.

Intenté la mayoría de las veces. Recuerdo haber visto un problema en GitHub donde alguien descubrió eso. Creo que fue en Meteor que un montón de, un montón de dev dependencies estaban siendo incluidas en el paquete de producción, que nuevamente, no son necesariamente necesarias en él. Algunas cosas como TypeScript, linters, ese tipo de cosas.

Intenté. Así que, estas se llaman dependencias directas. Pero recuerdas ese meme que te mostré antes, ¿verdad? Con los objetos más pesados del universo. ¿Qué pasa con las que las dependencias que se instalan a través de otras dependencias? Y estas pueden colarse y simplemente hacer que la caja crezca en tamaño. Estas se llaman dependencias transitivas.

Intenté, pero esas no son solo, no son los únicos tipos de dependencias con las que podemos trabajar. También hay dependencias peer. Y las dependencias peer son dependencias que vamos a ver más a menudo si estamos trabajando en un paquete nosotros mismos. Son dependencias con las que nuestro paquete es compatible o está destinado a ser utilizado. Te daré un ejemplo. Puedes ver aquí, estoy trabajando en un paquete llamado fancy charts. Y estoy declarando como una dependencia peer, chart.js. Y lo que esto significa es que cuando alguien va a usar e instalar, intenté fancy charts, chart.js se instalará junto con fancy chart, no como una dependencia, sino como una dependencia peer.

Intenté, intenté. Y hay un lugar más que miramos cuando hablamos de dependencias en nuestros proyectos de React. Intenté, intenté el archivo package lock. ¿Alguno de ustedes ha entrado aquí y mirado alrededor? Porque es una locura. Quiero decir, solo mira mi editor de texto aquí. Línea seis, espera, 16,427. Es un archivo sustancioso. Y tengo que admitir, principalmente trabajo con él cuando tengo conflictos de fusión. Intenté. Así que, sí. Estos son diferentes lugares donde estamos mirando lo que el archivo package lock JSON hace, por cierto, es declarar exactamente qué versiones de esas dependencias vamos a estar instalando si alguien va, quiere ir y desarrollar y trabajar en nuestro proyecto. Intenté, está bien. Esos son los tipos de dependencias.

Intenté. Estamos empezando a trabajar con ellas. Y traté de encontrar problemas mientras estaba con React Native. Quiero insistir nuevamente en ese poder de la comunidad. Intenté que la gente trabaje en herramientas increíbles que ayudan a trabajar en, que nos ayudan con trabajar en nuestras dependencias. Y quiero mostrarte solo un par. Hay diferentes para diferentes gestores de paquetes que usas.

Por ejemplo, yarn upgrade interactive o NPM check updates. Y estas herramientas son increíbles. Voy a mostrarte yarn upgrade interactive rápidamente porque lo que hace es mostrarte qué dependencias en tu proyecto tienen actualizaciones disponibles a las que puedes actualizar y cuáles son Intenté actualizar o podrían ser cambios disruptivos. Hablaremos más sobre eso más tarde. Creo que esto es absolutamente maravilloso cuando solo necesito como, ya sabes, pulir un proyecto y ver qué necesita actualizaciones.

Pero también hay herramientas específicas para los entornos en los que estás trabajando. Como intenté, no puedo decirles cuánto el React Native upgrade helper me ha salvado el trasero tantas veces a lo largo de los años. Porque lo que te permite hacer es decir, genial, ¿con qué versión estás trabajando ahora? ¿A qué versión te gustaría actualizar? Y te dará no solo instrucciones sobre cómo actualizar, sino también una diferencia del archivo de configuración para que puedas ver, genial, ya no estamos usando esto. Lo cambiamos por algún otro empaquetado, cosa, todo eso. Es realmente poderoso. Y estoy muy agradecido a las comunidades por hacer posible que trabajemos más fácilmente con nuestras herramientas.

Intenté Intenté, intenté esas herramientas que nos ayudan, intenté, intenté e interactuar con nuestras dependencias. ¿Qué pasa cuando estamos atascados? Después de todo, como desarrolladores de software, somos solucionadores de problemas. Nos atascamos mucho. Al menos yo lo hago. Intenté, bastante seguro de que muchos de nosotros lo hacemos. Intenté, intenté descomponer el problema en partes más pequeñas es una herramienta tan poderosa para ayudarme a concentrarme y hacer el trabajo. Intenté, intenté, intenté que te encuentres con el problema, error resuelto, no se pudo resolver. Algo sobre no se pudo resolver la dependencia React depende de esto. Pero este otro proyecto, esta otra dependencia depende de eso. Es una pesadilla trabajar con eso. Entonces, ¿qué hago? Descompongo el problema. Intenté recordar cuando estaba trabajando con este proyecto de React Native, no podía hacer que la compilación de iOS se ejecutara y no podía hacer que la compilación de Android se ejecutara.

Entonces, ¿qué hago? Lo intenté uno a la vez. Ups, lo siento. Me emocioné. Lo intenté. Así que, genial. Solo me voy a concentrar en hacer que la compilación de iOS funcione y luego voy a desglosar ese problema en problemas más pequeños y solo me concentraré en uno a la vez. Primero, vamos a adaptarnos al auto-linking. Hecho. Arreglar errores de compilador. Hecho. Elementos de UI rotos, arréglalo. Bugs introducidos por la actualización. Arreglado. Advertencias del compilador, arregladas.

Y una vez que eso esté hecho, he terminado con iOS. Ahora me voy a concentrar solo en Android. Lo mismo que antes. Tick, tick, tick, tick, tick, tick, tick. Arreglar todo. Aún asegurarme de que la compilación de iOS esté funcionando. Oh, en realidad, al intentar hacer que la compilación de Android funcione, de alguna manera rompí la de iOS. Pero está bien. No me di cuenta de eso hasta el final porque me estaba concentrando en un problema a la vez.

Intenté, intenté, intenté, intenté tener un videojuego. Me voy a envejecer mucho al referenciar esto, pero espero que haya alguien en la audiencia que sepa o recuerde Greenhouse de Game & Watch. Me duele que esto sea de 1982. Pero lo jugué en el Game Boy. Pero el punto es, estás jugando como un jardinero cuidando su jardín y hay alimañas entrando para, como, comer tus cultivos y se supone que debes, como, golpearlos con un spray. Intenté realmente, de nuevo, es ese enfoque de un bug a la vez. ¿Ves lo que hice ahí? Porque es programación y hay bugs.

De todos modos, de nuevo, intenté mantenerme enfocado. Solucionar un problema a la vez. Eso es lo que hacemos todos los días como desarrolladores de software y lo mismo se aplica a eso como gestores de dependencias.

Intenté, intenté, intenté. Ahora, intenté pensar en las dependencias, especialmente como desarrolladores de React. Vamos a discutir un poco sobre herramientas. Estoy bromeando. No vamos a discutir sobre herramientas. Y, por supuesto, intenté súper importante y no sé. Soy un gran creyente en no tanto, como, hay una herramienta que se adapta a todo, sino más bien elegir la herramienta adecuada para el trabajo adecuado.

Y podemos discutir sobre si Yarn o NPM o PMPM es mejor. Dato curioso, por cierto, al escribir esta charla, fue una de esas cosas donde estaba, como, ¿qué significa PMPM? ¿Qué significa la P en PMPM? Significa performante, lo cual tiene sentido. Y probé los beneficios entre Yarn y NPM y PMPM es importante para asegurarse de que estás haciendo el trabajo que necesitas hacer. Y, de nuevo, es una de esas cosas donde no hay una talla única para todos.

Lo intenté, lo intenté. Además, no se trata solo de gestores de paquetes. También se trata de herramientas que te ayudan a averiguar, por ejemplo, de dónde provienen tus dependencias.

Lo intenté, me encanta NPM why. Porque lo que puedes hacer es simplemente decir en tu terminal NPM why deqol, por ejemplo. Vamos con deqol. Y luego te dirá qué subdependencias dependen de deqol y de qué versiones son.

Lo intenté, esto es extremadamente útil cuando estás tratando de eliminar esas dependencias que realmente ya no necesitas. Lo intenté, lo intenté, lo intenté. ¿Por qué hacerlo tú mismo si puedes dejar que una herramienta lo haga automáticamente por ti? Clip es una herramienta realmente poderosa para descubrir qué archivos no utilizados, dependencias y exportaciones SSS en el sitio web ya no necesitas. Es una herramienta fantástica. Un saludo a Josh por presentármela.

Lo intenté, lo intenté. Bien. Hasta ahora hemos estado hablando de proyectos con probablemente un conjunto de dependencias, ¿verdad? ¿Qué pasa con los monorepos? Y no voy a entrar en una discusión aquí sobre si los monorepos son buenos o malos. Solo voy a reconocer el hecho de que hay proyectos que los utilizan.

Lo intenté, si no estás familiarizado, los monorepos son una forma de tener, lo intenté bases de código que idealmente comparten dependencias o comparten un repositorio. Lo intenté, lo intenté una de las formas fenomenales de hacer esto es Yarn workspaces, que nuevamente, te permite tener varios bases de código en un repositorio que comparten dependencias. De hecho, Yarn usa esto. Yarn usa Yarn workspaces para tener cosas como el sitio web, el paquete en sí, teniendo múltiples paquetes, todo en un repositorio, todo en una base de código compuesta por varias bases de código.

Lo intenté, lo intenté, y X hace lo mismo, incluyendo herramientas súper poderosas para CI y otras automatizaciones para trabajar y hacer que trabajar en bases de código complejas sea mucho más sencillo. Lo intenté, lo intenté, lo intenté, lo intenté, lo intenté, lo intenté, y luego está npm shrinkwrap. No sé si has oído hablar de él. Estas son herramientas que vienen con npm, que siempre encuentro tan fascinantes.

Lo intenté, y en concepto, npm shrinkwrap crea un archivo de bloqueo, muy similar a lock json. Lo intenté, lo intenté, cambia eso con la diferencia de que intenté incluirlo al publicar un paquete, y podrías pensar, ¿por qué demonios necesitaría eso? Por ejemplo, intenté mis herramientas usando algo como npm publish te permitirá publicar este archivo de bloqueo shrinkwrap. Lo intenté, lo intenté, recuerda cuando estábamos hablando de actualizar dependencias, también hay herramientas como npm audit para ayudarte a descubrir cuál de tus dependencias está desactualizada, tiene una brecha de seguridad y necesita una actualización urgente, lo cual nuevamente, no tiene que hacerse a mano. También puede hacerse automáticamente por servicios como Dependabot, Snyk y Renovate.

Lo intenté, lo intenté, así que genial, esas son algunas herramientas para trabajar con dependencias. Intenté al hacer esas actualizaciones, ¿cuán grande es el salto que hacemos? Lo intenté, intenté tomar la decisión de, oh, simplemente voy a ir hasta la última versión, porque cuando estaba trabajando en este proyecto, ¿verdad? Podría haber tomado la ruta de actualizar de React Native 55 a 59, asegurarme de que todo funcione, y seguir desde allí. 59 fue un hito, porque introdujo algunas cosas de JavaScript para Android, en general, para hacer todo más eficiente con React Native. Lo intenté, habría pasado de React Native 55 a React Native 60.

Lo intenté, lo intenté, intenté todos los módulos nativos para hacer cosas como trabajar con la cámara y ese tipo de cosas están vinculados automáticamente, lo que significa que no tengo que hacer ningún complicado, ¿cómo se llaman?, vinculación de dependencias con las compilaciones de iOS y Android, respectivamente. Lo intenté, lo intenté, pero fui hasta 0.74.

Lo intenté, podrías preguntarte por qué, eso suena realmente doloroso, y la respuesta a eso es un por qué no bastante descarado. Lo intenté, lo intenté, porque intenté avanzar un poco y simplemente dejarlo como está, pero aquí está la cosa, no solo me aseguro de que estoy en la versión más estable, recuerda, cuando trabajas con algo como React Native, no solo dependes del proyecto de JavaScript el proyecto React, el proyecto React Native, también dependes de los caprichos de Apple y Google haciendo cambios en sus plataformas, por lo que mantenerse actualizado es una muy buena idea con este tipo de cosas. Pero también, lo intenté, lo intenté, va a suceder eventualmente, mejor sacarlo del camino. Lo intenté, y luego puedes adoptar un flujo de trabajo de hacerlo más a menudo. Intenté otra cita de Martin Fowler que escribe, si duele, hazlo más a menudo. Tiene la propiedad feliz de parecer sin sentido en la superficie pero ofrecer un significado valioso cuando profundizas.

Quiero tomar un momento para predicar una de mis prácticas favoritas para el control de versiones, que se llama la rama bleeding edge. No sé si has oído hablar de esto, en realidad se menciona en el manual de Git como algo que puedes hacer, que es tener una rama que es como un sandbox, una especie de bloc de notas, donde tienes commits pequeños, probablemente rotos, donde simplemente estás actualizando algo y está roto, algo más está roto, simplemente sigue haciendo commits para que puedas tener un historial al que puedas volver para entender cuáles fueron los pasos que tomaste al hacer esta actualización de dependencias, pero también lo hace extremadamente fácil de rebasear.

Intenté, intenté, intenté, intenté hasta el final, intenté, creo que también es realmente importante saber si necesito actualizar todas mis dependencias de una vez. Intenté, en el proyecto en el que estaba trabajando había 72 dependencias y no las actualicé todas y no las actualicé completamente. Intenté mirar algo como el versionado semántico, sabes donde el número a la izquierda es un número de ruptura de API mayor, la versión menor son nuevas características que no rompen nada en retrospectiva, y el número más a la derecha es la versión de parche que solo introduce correcciones de errores y es una buena idea, relativamente una buena idea mantenerlos actualizados.