El día que rompí React Native

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

4 de noviembre de 2022 - Era solo un día normal para el "equipo de lanzamiento" mientras nos preparábamos para preparar el primer candidato a la liberación para React Native 0.71. Poco sabíamos cómo un lanzamiento inocuo podría haber desencadenado un efecto dominó que resulta en compilaciones fallidas para casi todos los desarrolladores de React Native.


Con la sabiduría de la retrospectiva, repasaremos lo que sucedió, cuáles son nuestras lecciones aprendidas y los puntos bajos de este incidente. Tendremos la oportunidad de mirar a través de las entrañas de React Native, descubrir nuestra cultura de respuesta a incidentes y aprender cómo estamos fortaleciendo nuestro ecosistema para protegernos contra eventos similares en el futuro.  


Únete a mí mientras revivimos este incidente, y no pierdas esta oportunidad de obtener información, inspirarte y abrazar las lecciones aprendidas del día que rompí React Native.

This talk has been presented at React Day Berlin 2023, check out the latest edition of this React Conference.

FAQ

La Starbucks Reserve Roastery en Seattle es un lugar especializado donde se realizan catas de café. Es ideal para los aficionados al café que desean explorar diferentes sabores y preparaciones.

El incidente involucró un problema donde las compilaciones de React Native comenzaron a fallar debido a una versión inestable (0.71.0.rc0) que se publicó erróneamente en Maven Central, causando que las compilaciones que usaban dependencias dinámicas se rompieran.

El problema se solucionó lanzando parches para todas las versiones de React Native hasta la 0.63, cubriendo el 99% de las descargas, y eventualmente eliminando los artefactos problemáticos de Maven Central con la ayuda de Sonotype.

Tras el incidente, el equipo de React Native implementó mejores prácticas y soluciones preventivas en su infraestructura, eliminaron muchas dependencias dinámicas y consideraron establecer una ventana de soporte de lanzamiento para versiones compatibles.

Maven Central es un repositorio donde se distribuyen las bibliotecas de Android, incluyendo los artefactos de React Native. Esencialmente, es un cubo S3 utilizado para almacenar bibliotecas que son demasiado grandes para ser incluidas en el paquete NPM.

El paquete NPM de React Native se volvió demasiado grande, superando los 200 megabytes, lo que llevó a problemas con la publicación en NPM. Esto forzó al equipo a mover los artefactos de Android a Maven Central para manejar mejor el tamaño y la distribución.

La 'dependencia plus' en Gradle permitía obtener la versión más alta disponible de una biblioteca, lo que causó que las compilaciones comenzaran a usar una versión inestable recién publicada en Maven Central, rompiendo así las compilaciones existentes.

Nicola Corti
Nicola Corti
30 min
08 Dec, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute un incidente en el que un lanzamiento de React Native provocó compilaciones fallidas y cómo se solucionó. El incidente ocurrió debido a que el paquete NPM se volvió demasiado grande, lo que llevó al traslado de los artefactos de Android a Maven central. El uso de versiones dinámicas y la dependencia plus en React Native se identificaron como factores contribuyentes al problema. Las lecciones aprendidas incluyen la importancia de eliminar las dependencias plus y la necesidad de mejores recomendaciones para crear bibliotecas resistentes.
Available in English: The day I broke React Native

1. El Día Que Rompí React Native

Short description:

Hola a todos. Hoy quiero contarles una historia de un lluvioso día de noviembre del año pasado en Seattle. La gente comenzó a informar sobre compilaciones de React Native rotas, y descubrimos que una próxima versión de React Native estaba causando el problema. Yo, Nicola Corti, ingeniero de Android en Meta, les guiaré a través del incidente y cómo lo solucionamos.

Hola a todos. Así que hoy quiero contarles una historia. Es la historia de un lluvioso día de noviembre del año pasado. Estaba en Seattle. Si alguna vez han estado en Seattle, asegúrense de visitar la Starbucks Reserve Roastery. Es un Starbucks especial donde hacen catas de café. Si te gusta el café, definitivamente querrás echarle un vistazo. Y yo estaba allí. Estaba revisando mi correo electrónico, revisando mis notificaciones de GitHub. Y sí, todo parecía genial. Pero luego la gente comenzó a enviarme mensajes de que por alguna razón sus compilaciones, sus compilaciones de React Native estaban rotas. Y bueno, estaba en Discord. Así que déjame ver qué está pasando realmente.

Y en React Native, ejecutarás Android para ejecutar la aplicación Android. Y la gente comenzó a informar sobre mensajes de error de la nada, de una manera realmente terrible. Imagina que tu compilación estaba funcionando hace un minuto, luego vuelves a compilar, no haces ningún cambio de código y tu compilación está rota. Esto es terrible desde el punto de vista de la experiencia del desarrollador. Y obviamente no debería suceder. Luego comenzamos a investigar, oye, ¿por qué estas compilaciones se están rompiendo realmente? Y nos dimos cuenta de que en el mensaje de error, se mencionaba una próxima versión de React Native, como 0.710.rc0. E incluso para los usuarios que estaban en versiones anteriores de React Native, como en 68 y 69 y así sucesivamente. En ese punto, nos dimos cuenta, sí, creo que tenemos un problema. Y personalmente tuve un gran problema porque se suponía que debía volar de regreso a Londres en un par de horas. Entonces, ¿cómo lo solucionamos?

Así que mi nombre es Nicola Corti. Trabajo como ingeniero de Android en el equipo de React Native en Meta. Y hoy estoy emocionado de contar la historia del día en que rompí React Native. Para entender completamente qué fue esto, les guiaré a través de lo que sucedió, qué fue el incidente real, por qué se rompió y cómo lo solucionamos realmente. Así que la advertencia aquí es, bueno, el incidente fue en Android, pero efectivamente rompimos la compilación para todos. Así que bueno, no muchas personas aquí usan React Native, pero confíen en mí, hay muchas lecciones aprendidas que se aplican a cualquier tecnología. Así que comencemos con lo que sucedió. Dentro de React Native y dentro del equipo de React Native, tenemos este grupo de personas llamado el equipo de lanzamiento.

2. Proceso de Lanzamiento de React Native

Short description:

El equipo responsable de los lanzamientos de React Native ejecuta el script Bump.OSS version con la próxima versión. El primer candidato a la liberación, RC0, se envía para pruebas. En 0.71, el paquete NPM se volvió demasiado grande, lo que llevó a la mudanza de los artefactos de Android a Maven central.

Son responsables de elaborar nuevas versiones de React Native cada cuatro a seis meses. Y lo que hacen, lanzan el script desde la consola, que se llama Bump.OSS version, con la próxima versión que tienen la intención de lanzar. Cuando cortamos una nueva rama, hacemos el RC0, que es el primer candidato a la liberación. El primer candidato a la liberación generalmente es inestable. Simplemente lo cortamos y lo enviamos al mercado para que la gente pueda comenzar a testing y decirnos si hay problemas de integración o regresiones. Así que 0.71, que fue a principios de este año, en realidad, fue bastante grande, y hubo muchos cambios dentro.

3. Traslado de los artefactos de Android a Maven Central

Short description:

Un cambio realmente relevante para este incidente es este RFC 508, que es la solución fuera del paquete NPM para los artefactos de React Native. El paquete NPM de React Native se estaba volviendo demasiado grande, por lo que decidimos mover los artefactos de Android del paquete NPM a Maven Central. El incidente ocurrió porque el paquete se estaba volviendo demasiado grande, y tuvimos que eliminar los binarios del paquete NPM.

Un cambio que es realmente relevante para este incidente es este RFC 508, que está fuera de la solución del paquete NPM para los artefactos de React Native. Prácticamente hablando, el paquete NPM de React Native se estaba volviendo demasiado grande. Ya no podíamos caber allí, y entraré en ello en un minuto. Pero tuvimos que encontrar una solución alternativa donde se pudieran enviar los artefactos de Android.

Cuando haces nativo, no solo distribuyes código, distribuyes binarios, y esos binarios se vuelven bastante grandes, y pueden llegar a cientos de megabytes. Así que decidimos mover los artefactos de Android del paquete NPM a Maven Central, que es donde generalmente se distribuyen las bibliotecas de Android. Así que este sitio web, que es bastante arcaico a juzgar por la cantidad de CSS que utilizan, es en realidad Maven Central. Así que no es más que básicamente un cubo S3 donde se almacenan las bibliotecas de Android. Y aquí es donde se almacena en realidad React Native y la gente que construye React Native lo obtiene de allí. Y si miras en la lista de versiones, verás que, bueno, solíamos publicar en Maven Central en el pasado. Si miras las versiones entre 0.11 y 0.20, que es como 2015, 2016, solíamos publicar allí. Pero luego en algún momento nos mudamos porque publicar en Maven Central era demasiado complicado, y entonces dijimos, está bien, hagamos un paquete monolítico y pongamos todo dentro del paquete de React Native. Bueno, entonces tuvimos que revertir esta decisión porque el paquete se estaba volviendo demasiado grande y publicamos 0.71.0.rc0, que ves justo debajo de allí, publicado en noviembre de 2022. Aquí.

Así que intentemos entender por qué ocurrió el incidente en primer lugar. Porque hasta ahora parece razonable. Cuando estábamos publicando en Maven Central en el pasado, volvíamos allí porque el paquete se estaba volviendo demasiado grande. Por qué las cosas se rompieron. Así que volvamos a este RFC y miremos más de cerca dentro del paquete npm. Como dije, la carpeta de Android era la mayor infractora aquí. Estamos hablando de 66 megabytes y en 0.71 estábamos añadiendo símbolos de debug y más cosas para mejorar la experiencia del desarrollador de Android, lo que hizo que el paquete de npm se hiciera más grande. Estaba llegando a más de 200 megabytes. Curiosamente, no puedes publicar paquetes de npm que superen los 220 megabytes o así porque npm te devolverá HTTP 4.1.3 contenido demasiado grande. Así que npm simplemente no era una opción. Así que tuvimos que eliminar esos binarios del paquete npm. El problema subyacente que desencadenó este incidente es lo que llamamos una dependencia plus, que es realmente similar a una dependencia de estrella en npm. Así que para Android, usamos Gradle para construir, y dentro del archivo Gradle tenemos un bloque donde describimos cuáles son nuestras dependencias, como qué bibliotecas queremos depender. Y una de estas es React Native. Esta cadena aquí se llama coordenadas maven gav. Sé que esto es muy específico para Android, pero también es bastante fácil de entender.

4. Entendiendo gav y Versiones Dinámicas

Short description:

gav significa grupo, artefacto y versión. La plantilla predeterminada para las aplicaciones de React Native incluye archivos Gradle con comentarios interesantes. Un comentario suprime una advertencia por el uso de versiones dinámicas, que se consideran un antipatrón en el espacio de Android. Las versiones dinámicas pueden llevar a compilaciones irreproducibles y dependencia de los mantenedores de la biblioteca.

Entonces, gav significa grupo, que es la organización que publica una biblioteca, a para artefacto, que es el nombre de la biblioteca, y v para versión, que en este caso era más, lo que significa simplemente obtener la versión más alta que encuentres en cualquier repositorio y usarla.

Bueno, si miramos como esto es de la plantilla predeterminada. Entonces, cuando creas una nueva aplicación de React Native, tendrás como archivo Gradle y cosas como esos comentarios aquí, que creo que son un poco interesantes.

Entonces, por ejemplo, hay un comentario aquí justo arriba que dice no inspección Gradle versión dinámica. Esto es una supresión de una advertencia para la línea justo debajo. La línea de abajo contiene un más, que, bueno, en el espacio de Android es un antipatrón. Específicamente, hay esta página en la documentación de Gradle, que se llama manejo de versiones con cambios a lo largo del tiempo. Entonces, como versiones dinámicas. Y solo en la primera, como si tomo una captura de pantalla de esta página, tienen dos advertencias que te dicen que las versiones dinámicas no son geniales porque simplemente llevan a compilaciones irreproducibles. Básicamente estás a merced del mantenedor de la biblioteca. Si el mantenedor de la biblioteca mañana publica una nueva versión, simplemente la vas a obtener y tal vez tu compilación se rompe de la noche a la mañana. Entonces, no es genial, ni en NPM ni en ninguna otra plataforma que tenga un concepto similar.

5. Entendiendo la Dependencia Plus en React Native

Short description:

Para entender por qué ocurrió el problema, necesitamos mirar la dependencia plus en React Native. Anteriormente, la dependencia se obtenía del paquete NPM, pero luego se trasladó a otro repositorio. La dependencia plus recupera la versión más alta disponible, causando problemas cuando se publica una versión superior. Esto llevó a que los proyectos utilizaran la versión 0.71.0.rc0, lo que causó problemas.

Pero, ¿por qué funcionó? Para entender completamente, necesitamos ver este otro comentario a la derecha, que dice de node modules. Así que la dependencia plus funcionó hasta React Native 0.70 porque en realidad estábamos obteniendo la dependencia del paquete NPM. Si empiezas a mirar lo que hay dentro de node modules, React Native, añade la carpeta Android, veremos que básicamente allí tenemos una colección de artefactos. Tenemos como un sources.jar, un archivo pom y así sucesivamente. Esto es como cosas de Java que se utilizan para construir las aplicaciones Android. Estoy fingiendo un poco aquí, como que la lista es en realidad bastante más larga. Pero independientemente de eso, esta es la lista de artefactos que utiliza React Native para construir una aplicación Android, como el núcleo de React Native. Y si miras en Maven Central, ese es en realidad el mismo contenido. Así que simplemente movimos esa carpeta de node modules a otro repositorio. Así que ahora tal vez empieces a entender por qué ocurrió el problema. El problema ocurrió porque la dependencia plus significa obtener la más alta. Y mientras añadas solo una versión localmente dentro de tus node modules y una versión en Maven Central, que era menor, en este caso 0.20, las cosas funcionaban bien. Pero si publico algo en Maven Central o en cualquier otro repositorio que tenga una versión superior, esa versión prevalecería en todos los proyectos de este planeta. Así que la gente empezó a agarrar esa versión 0.71.0.rc0, lo cual no es genial.

6. Arreglando las Compilaciones de React Native

Short description:

Para solucionar el problema, lanzamos parches para todas las versiones de React Native hasta la 0.63. Esto requirió un esfuerzo significativo, ya que tuvimos que trabajar con ramas de lanzamientos realizados hace años. Fuimos más allá para proporcionar una versión parcheada de React Native que solo incluía las correcciones necesarias. Además, nos pusimos en contacto con Sonotype, la empresa que administra Maven Central, para que se eliminaran los artefactos. Aunque llevó algún tiempo, esta fue la solución definitiva al problema. De esta experiencia, aprendimos la importancia de eliminar las dependencias plus.

Entonces, veamos cómo lo solucionamos realmente. ¿Cómo podemos arreglar las compilaciones para todos? Entonces, podrías pensar, está bien, entonces voy a mi proyecto y simplemente elimino el plus, ¿no? Especifico la versión que estoy usando, como 0.68, ¿no? Como si hubiera parcheado mi proyecto local. Bueno, eso es cierto, pero también un poco ingenuo porque en React Native, dependemos mucho de las dependencias externas, como en todos los proyectos node. Por ejemplo, una biblioteca muy popular para React Native es reanimated, una biblioteca de animación. Y también tienen un archivo griddle. Y dentro de su archivo griddle, también dependen de React Native. Y bueno, reanimated no quiere depender de una versión específica de React Native, solo quieren obtener la que el usuario está usando. Así que también tienen una dependencia plus en su archivo griddle. Eso significa que incluso si tu proyecto especifica 68, reanimated diría como, no, no, no 68, dame la más alta, quiero esa. Así que básicamente cada biblioteca estaba contribuyendo a romper el proyecto aún más.

¿Entonces cómo lo arreglamos? Básicamente estaba en el avión, esperando a despegar y abrí un problema en GitHub tratando de explicar cuál es el problema, y con una combinación de paquetes de parches y demás, cómo podemos mitigar efectivamente este problema en tu proyecto. Pero esto no era ideal, el hecho de que tuvieras que usar el paquete de parches o hacer ediciones locas en tu carpeta de módulos node no es ideal. No deberías estar haciendo eso. Así que, junto con el resto del equipo de lanzamiento y personas de la comunidad, lanzamos parches para todas las versiones de React Native hasta la 0.63. Y esto fue un gran esfuerzo, porque imagina que tienes una rama para un lanzamiento que hiciste hace tres años. No sabes si el CI está funcionando, no sabes cuál es el estado allí. Y quieres intentar lanzar una nueva versión desde allí. No es fácil. Bueno, lo logramos y realmente hicimos un esfuerzo extra, la gente trabajó toda la noche para arreglarlo de manera que solo tendrías una versión parcheada de React Native que contiene solo las correcciones necesarias para resolver el problema. Y bajamos hasta la 63 porque mantenemos un ojo en la cuota de mercado de las diversas versiones de React Native que ustedes descargan de NPM. Y 63 nos permitió cubrir el 99% de las descargas. Así que básicamente pudimos arreglarlo para todos. La solución definitiva, en realidad, fue contactar a Sonotype, que es la empresa que administra Maven Central y pedirles que eliminaran los artefactos. Esto llevó un poco más de tiempo, como dos días, porque inicialmente pensamos, está bien, nunca van a eliminar eso. Como Maven Central es un almacenamiento de datos inmutable, no se supone que debas eliminar bibliotecas. Pero en este caso, esta fue la única solución a este problema. Así que también nos ayudaron mucho en arreglar esto.

Ahora quiero compartir un par de lecciones aprendidas, cosas que yo y el resto del equipo de lanzamiento y el equipo de React Native nos llevamos de esta experiencia. Entonces, primero, muchas de las dependencias plus han sido eliminadas.

7. Soporte de React Native y Cultura de Incidentes

Short description:

Hemos implementado soluciones en nuestra infraestructura de Android e iOS para prevenir problemas similares. Ahora tenemos una ventana de soporte de lanzamiento que declara qué versiones de React Native admitimos. Esto cubre casi el 70-75% de la cuota de mercado y proporciona una ventana de un año para recibir parches y actualizaciones de seguridad. Reconocemos que nuestro tiempo de respuesta al incidente fue lento en este incidente de código abierto. En Meta, utilizamos niveles SEV para expresar la gravedad de un incidente, siendo SEV2 el nivel para problemas mayores. Las bibliotecas también contribuyen al problema al copiar patrones que pueden contener anti-patrones.

Como tenemos soluciones en marcha dentro de nuestra infraestructura tanto de Android como de iOS para prevenir problemas similares a este. Y también hemos considerado implementar lo que se llama una ventana de soporte de lanzamiento. Históricamente, se recomendaba estar en la última versión de React Native, lo cual sí funciona, pero no siempre es posible porque tu proyecto puede quedarse un poco atrás. Así que ahora somos más intencionales sobre qué versiones de React Native son realmente compatibles. Si miras en el grupo de trabajo de lanzamientos de React Native para React, verás que declaramos qué versiones de React Native admitimos. Y cuando decimos que admitimos, queremos decir que si encuentras un error en una de esas versiones, nos comprometemos a solucionarlo y lanzar un parche para ti. Esto cubre casi el 70, 75% de la cuota de mercado hasta ahora. Y esto permite cubrir un año entero de lanzamientos. Así que eso significa que aunque deberías actualizar tu versión de React Native y cualquier versión de dependencia que uses, tienes una ventana de un año para poder recibir siempre parches y parches de seguridad y demás.

Otra cosa que aprendimos es el tiempo de respuesta a incidentes. Personalmente creo que fuimos bastante lentos para responder aquí. El problema es que este fue un incidente de código abierto. No tenemos ninguna telemetría en React o React Native, así que no sabemos cómo van las cosas para ti. Como no sabemos si tus compilaciones están rotas. No sabemos qué dependencias usas y así sucesivamente. Así que el hecho de que alguien me dijera que su compilación está rota, no tengo la sensación de que esto significa que todas las compilaciones en el planeta están rotas. Así que quiero tocar un poco la cultura de incidentes en Meta para que entiendas cómo intentamos integrarnos dentro de la cultura de Meta y el espacio de código abierto. En Meta, utilizamos niveles SEV, que son como un estándar de mercado para expresar la gravedad de un incidente. Tenemos SEV4, que es el nivel más bajo, que es solo un aviso. Abrimos un incidente SEV4 siempre que hay algo que podría romperse, pero tal vez no. Por ejemplo, hicimos una gran migración de la estructura del monorepo de React Native, y siempre que mueves mucho código, las cosas pueden romperse. Por eso abrimos un SEV4 para ese caso. Tenemos SEV3, que significa problema significativo, la resolución es de moderada a alta prioridad, como algo se rompió, alguien debería mirarlo. SEV2, que es un problema mayor, la resolución es de muy alta prioridad, como un grupo significativo de personas se ve afectado. SEV1, alerta roja, todos a bordo, como generalmente uno de los productos de Meta está caído. Y luego SEV0, que significa crisis a nivel de empresa, como varios productos están caídos o las cosas están realmente mal. En este caso, esto fue un SEV2 porque todo el ecosistema de código abierto de React Native estaba roto, y tuvimos que despertar a la gente y encontrar una solución lo antes posible.

Otra cosa que nos llevamos a casa son las mejores prácticas de las bibliotecas. Como dije antes, las bibliotecas estaban contribuyendo a exacerbar el problema aquí porque cada una tiene su propia lógica de construcción, y pueden hacer, básicamente lo que pasa es que hay patrones en la comunidad que se copian. Tal vez empiezas una nueva biblioteca y copias otra biblioteca, y tal vez hay un anti-patrón allí que se pasa de una biblioteca a otra.

8. Inversión en la Creación de la Biblioteca React Native

Short description:

Estamos invirtiendo en la creación de la biblioteca React Native para proporcionar mejores recomendaciones para la creación de bibliotecas resilientes. Lecciones aprendidas: evitar los envíos los viernes, la liberación tuvo suerte de ocurrir durante el fin de semana, y los incidentes en un avión son desafiantes. Lee el análisis post-mortem en el blog de React Native para obtener más detalles técnicos.

Es por eso que estamos invirtiendo en la creación de la biblioteca React Native, que es nuestro punto de entrada para crear nuevas bibliotecas. Hay un RFC abierto en el sitio web, que es la plantilla dorada para la creación de la biblioteca React Native. Así que queremos ofrecer mejores recomendaciones que estén aprobadas por Meta sobre cómo crear bibliotecas para React Native que sean resilientes a incidentes como este.

Y luego, bueno, un par de otras lecciones aprendidas que son bastante personales, pero se aplican a todos, creo. El día en que se invocó este script, fue un viernes. Así que incluso si estás trabajando en móviles, no hagas envíos los viernes. Y bueno, en este caso particular, en realidad, si miras la rama de lanzamiento de React Native 71, cada vez que ves un número de versión de revert bump, es un intento de publicar una versión que falló y se reinició. Sí, para ser justos, se suponía que este lanzamiento se iba a realizar el martes, y luego pasaron al jueves, y luego al viernes, y asumieron que todo funcionaría. Bueno, ese no fue el caso. Creo que en este escenario particular, en realidad, el hecho de que lanzáramos el viernes fue suerte. Tuvimos mucha suerte de que un problema como este surgiera durante el fin de semana para que tuviéramos tiempo durante el fin de semana para preparar lanzamientos de parches para todas las versiones de React Native en el mercado. Pero si esto hubiera ocurrido el lunes por la mañana, habríamos interrumpido el flujo de trabajo de los bancos, de las personas que están usando React Native en producción, y no pueden debido a problemas como este. Así que creo que ahora no hacemos lanzamientos los viernes por si acaso. Pero en este caso particular, tuvimos suerte.

Y la otra cosa es que, el Wi-Fi de los aviones es realmente terrible. Y asegúrate de no tener que lidiar con incidentes en un avión porque especialmente si necesitas transferir grandes binarios como artefactos para móviles, bueno, te va a llevar una eternidad. Así que si estás interesado en aprender más sobre este incidente, en realidad publicamos un análisis post-mortem en el blog de React Native. Puedes leerlo. Entra en más detalles sobre las tecnicidades de este problema. Y con esto, quiero agradecerte mucho por escuchar.

9. Republicación en Maven y Eliminación de Versiones

Short description:

Mi única pregunta es, ¿cómo volviste a publicar en Maven o no lo hiciste? Volvimos a publicar en Maven con nuevas coordenadas, cambiando el nombre de la biblioteca a React Android. Implementamos alias para resolver las solicitudes de React Native a React Android. Se siguió el proceso de eliminar paquetes y publicar nuevas versiones. La respuesta de Sanatype fue positiva, y encontraron interesante la necesidad de eliminar una versión.

Mi única pregunta es, ¿cómo volviste a publicar en Maven o no lo hiciste? No. Entonces, sí, volvimos a publicar en Maven. Como que ahora las bibliotecas están en Maven Central. Y básicamente lo que hicimos, usamos nuevas coordenadas. Así que la biblioteca ya no se llama React Native, se llama React Android y sí. Sí, eso lo solucionará. Sí. Y también implementamos todas las cosas de alias. Entonces, si en tu archivo Gradle solicitas React Native, en realidad vamos a redirigir esa solicitud para resolver React Android. Sí, sí, porque creo que esa es una de las soluciones que es como, realmente no es posible ponerlo en el mismo lugar. Como que no creo que hubiera una solución rápida, es una de esas cosas que no tenías una solución rápida. Absolutamente.

Solo mira el profundo agujero del WiFi de Lufthansa. Estaba mirando a través de los como Sanatype usa Jira para interactuar con los clientes. Sí. Lo siento mucho por eso. No me sorprende. Básicamente, estaba mirando las solicitudes para eliminar paquetes y siempre estaban respondiendo como, no, nunca eliminamos nada. Solo publica una nueva versión de la biblioteca. Como si hubieras hecho una publicación falsa, puedes aumentar la versión. Sí, eso también es cierto en NPM y también en Crate para Rust, es lo mismo. Sí. Y yo estaba como, cada vez que publico, solo empeoraría esta situación. Como porque, ya sabes, hay esa versión que está ofendiendo porque su fuerza es mayor que las demás. Así que simplemente elimínalo. Y ellos fueron geniales en hacer eso. Creo que lo miraron y estaban como, ¿sabes qué? Nunca pensé que encontraría una razón por la que necesitaba eliminar una versión. Sí, como que encontré una. Absolutamente. Estaban como, su respuesta fue como, oh, eso es realmente interesante.

10. Lecciones Aprendidas y Pruebas Manuales

Short description:

Una de las lecciones aprendidas es no reutilizar cosas del pasado sin entender completamente las razones detrás de su uso. Mentalmente, me siento bien ahora, aunque hubo un momento de pánico. Pudimos solucionar el problema con la ayuda de mis colegas. Sin embargo, enfrentamos desafíos al parchear React Native 0.63 debido a las dependencias de software obsoletas. Es importante tener imágenes de docker del entorno de compilación para evitar fallos de compilación causados por cambios en las versiones de las herramientas. También tenemos un proceso de pruebas manuales y confiamos en las pruebas de CI y las pruebas internas en la infraestructura de materia.

Lo siento mucho. Pero sí, fueron realmente útiles en esto. Y sí, una de las lecciones que obtuvimos de esto es también no intentar reutilizar cosas que usaste en el pasado. Básicamente, quiero decir, en este caso, deberíamos haber hecho más arqueología de Git para entender completamente por qué se usaba Maven Central en ese momento. ¿Por qué ya no se usa? Como que pensamos, OK, está ahí, simplemente sigue reutilizándolo. Pero sí, volvió a surgir.

¿Cómo te sientes mentalmente ahora que ha pasado un tiempo desde que ocurrió eso? Bueno, está bien. El día que estaba como, oh, Dios mío, esto es realmente malo. Como, sabes, en la masterclass estoy como si estuviera en los negocios. Pero tuve suerte y estaba como, OK, intentemos solucionar lo máximo posible. Y como le pregunté a mi colega, estaban en ese momento en Andover, lo cual sí, quiero decir, pudimos solucionarlo. Pero durante el fin de semana, nos quedamos despiertos e hicimos todos los parches. Y realmente como un problema allí es como para cuando estaba diciendo como para hacer un parche de React Native 0.63, necesitas Xcode 13, y luego CircleCI es como, no, eliminé Xcode 13. Este es como software obsoleto. ¿Por qué lo necesitas? Y yo estoy como, necesito publicar una biblioteca de hace tres años. Y necesito Xcode 13 porque esto se construye solo con Xcode 13 y así sucesivamente. Así que creo que otra lección aprendida aquí, solo más técnica y en el lado de Android y Android e iOS, intenta tener imágenes de docker de tu entorno de compilación, porque si tú compilas allí en el CI, básicamente tan pronto como cambien la versión de Java o la versión de Node o cualquier versión de cualquier herramienta en ese entorno, ya no puedes compilar. Para Android, tenemos imágenes de docker por lo que puedo bajar a, no sé, versiones antiguas de React Native y decir como, OK, reconstruye eso.

Todos aparecieron. Todos aparecieron ahora. OK. OK. OK. Eso es grande. Lo siento por eso. Entonces, ¿tienes una prueba manual testing? Oh, ¿tienes un proceso de prueba manual testing antes de lanzar nuevas versiones? Sí, lo hacemos. Tenemos una serie de pruebas de CI, principalmente pruebas unitarias. Confiamos mucho en las pruebas internas que ejecutamos en la infraestructura de materia. Entonces, por ejemplo, cada vez que envías una solicitud de extracción contra React Native, la importamos internamente y ejecutamos Oculus contra ella. Ejecutamos Facebook contra ella.

11. Lanzamiento y Optimización de React Native

Short description:

Al lanzar React Native, probamos que puedes crear un proyecto e iniciar la aplicación de inmediato. Meta consume React Native desde la fuente, mientras que el código abierto tarda más tiempo en construirse. Nuestro objetivo es un rendimiento óptimo.

Entonces, si rompiste algo gravemente, lo descubriremos. Pero cuando hacemos un nuevo lanzamiento de React Native, probamos que eres capaz de crear un proyecto, que la nueva aplicación se inicia y así sucesivamente, porque la forma en que se utiliza React Native en código abierto e internamente en Meta es ligeramente diferente. Meta consume React Native desde la fuente, desde la principal. Entonces tus cambios van directamente a la aplicación de Facebook que sale la próxima semana. Mientras que para el código abierto, mientras se construye React Native lleva tiempo. Tienes más cuidado. Sí, quiero decir, obviamente, queremos asegurarnos de que con una línea de código, eres capaz de crear una nueva aplicación e iniciarla de inmediato sin depender de los cachés de compilación o algo así. Entonces, sí, simplemente intentamos hacerlo lo más óptimo posible.

12. Incidente SEV Zero y Reacción

Short description:

¿Alguna vez has recibido un SEV cero? Afortunadamente, nunca había recibido un SEV cero. En octubre de 2022, los servidores estaban caídos, y fue un incidente SEV cero. Me alegro de trabajar en móviles porque los incidentes en ese espacio no son tan graves como los de los servicios de producción. No hubo una cultura de culpabilidad alrededor del incidente, y la reacción fue arreglarlo lo más pronto posible para la comunidad de código abierto. Nos propusimos proporcionar la mejor solución e incluso consideramos crear versiones de parche para React Native para llegar a tantos usuarios como fuera posible.

Una pregunta más, ya que la cosa no aparecía, que es, ¿alguna vez has recibido un SEV cero? Y si es así, ¿cómo lo manejaste, cómo lo manejó alguien? ¿Alguien lloró? Así que nunca había recibido un SEV cero. Gracias. Afortunadamente. Pero si recuerdas, creo que en octubre de 2022, creo. Oh, los servidores estaban caídos o algo así. Sí, como que todo estaba caído. Como creo que Meta se cortó de internet y eso fue un SEV cero. Varias personas estaban despiertas y totalmente manos a la obra en eso. Me alegro de trabajar en móviles. Como siempre veo el Android. Así que los incidentes son bastante locos. Como si eso empieza a fallar, bueno, está bien, puedo hacer un nuevo lanzamiento y ponerlo en la tienda. Pero pasarán horas antes de que esté fuera, ¿sabes? Así que me alegro de no ser ingeniero de producción. No soy un SRE. Estoy de guardia a veces por cosas como el soporte de código abierto y cosas que necesitan atención inmediata o escenarios como este. Pero la gravedad de los problemas de código abierto que podemos tener nunca es tan alta como los servicios que están en producción.

OK, así que solo una más, porque siento que ganaste mucha tracción. Básicamente preguntaba si alguien se enfadó contigo. ¿Cuál fue la reacción de tu líder y compañeros de equipo? Espero que muchas otras empresas de tecnología allá afuera, no tengamos una cultura de culpabilidad alrededor de los incidentes. Los incidentes pueden suceder. En realidad no estaba en el equipo de lanzamiento. Como no envié ese script, no era responsable. Pero en realidad, escribí la infraestructura que causó esto. Así que me sentí responsable, obviamente. La reacción fue como, sí, rompimos cosas. Arreglémoslo lo más pronto posible, porque nos importa mucho nuestra community de código abierto. Así que intentemos darles la mejor solución. Como cuando añadimos esos fragmentos y parches por ahí, era como, seguro. ¿Pero podemos hacerlo mejor? ¿Podemos hacer versiones de parche para las versiones de React Native hasta el 99 por ciento de los usuarios? Sí, podemos.

13. Lecciones Aprendidas y Preguntas y Respuestas

Short description:

Al final del día, se aprendieron muchas lecciones. La lección aprendida es dejar de suprimir las advertencias y apuntar a cero advertencias. Si tienes más preguntas, hay una sala de preguntas y respuestas disponible. Por favor, regresa en nueve minutos para la innovación en el panel de React.

Así que hagámoslo. Entonces, sí, quiero decir, al final del día, se aprendieron muchas lecciones. Y sí, como no me han despedido por esto. Y creo que lo último que quiero decir es, ¿no es la lección aprendida para realmente dejar de suprimir las advertencias? Sí, sí. Soy un gran fan de ir a cero advertencias. No más TS ignores. Eso podría solucionarlo. Parpadea dos veces si estás a salvo. Sí, OK, seguro, seguro. En realidad, no parpadeaste. Está bien, estoy a salvo. Estoy a salvo. Estoy a salvo. Genial. Creo que hemos terminado. No, hemos terminado. Sí, pero él no parpadeó. Así que ahora estoy asustado. Parpadeé dos veces. OK, genial. Confía en mí. OK, sí. Entonces, si tienes más preguntas de nuevo, lamento el retraso que ocurrió aquí después. Sí, hay una pequeña sala de preguntas y respuestas allí. Y por favor, regresa en. Oh, eso no tiene el tiempo para hacerlo. Nueve minutos porque vamos a tener una innovation en el panel de react. Entonces, sí. Nos vemos a todos en nueve minutos.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Flat Routes – Una Evolución en el Enrutamiento
Remix Conf Europe 2022Remix Conf Europe 2022
16 min
Remix Flat Routes – Una Evolución en el Enrutamiento
Top Content
Remix Flat Routes is a new convention that aims to make it easier to see and organize the routes in your app. It allows for the co-location of support files with routes, decreases refactor and redesign friction, and helps apps migrate to Remix. Flat Folders convention supports co-location and allows importing assets as relative imports. To migrate existing apps to Flat Routes, use the Remix Flat Routes package's migration tool.
Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida
React Advanced 2023React Advanced 2023
29 min
Elevando el Listón: Nuestro Viaje Haciendo de React Native una Opción Preferida
This Talk discusses Rack Native at Microsoft and the efforts to improve code integration, developer experience, and leadership goals. The goal is to extend Rack Native to any app, utilize web code, and increase developer velocity. Implementing web APIs for React Native is being explored, as well as collaboration with Meta. The ultimate aim is to make web code into universal code and enable developers to write code once and have it work on all platforms.
Cómo hacer un juego web tú solo
JS GameDev Summit 2023JS GameDev Summit 2023
27 min
Cómo hacer un juego web tú solo
This talk guides you on how to make a web game by yourself, emphasizing the importance of focusing on tasks that interest you and outsourcing the rest. It suggests choosing a game engine that allows distribution on the web and aligns with your understanding and enjoyment. The talk also highlights the significance of finding fun in the creative process, managing scope, cutting features that don't align with the game's direction, and iterating to the finish line. It concludes by discussing the options for publishing the game on the web and leveraging unique web features.
Despliegue Atómico para Hipsters de JavaScript
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Despliegue Atómico para Hipsters de JavaScript
This Talk discusses atomic deployment for JavaScript and TypeScript, focusing on automated deployment processes, Git hooks, and using hard links to copy changes. The speaker demonstrates setting up a bare repository, configuring deployment variables, and using the post-receive hook to push changes to production. They also cover environment setup, branch configuration, and the build process. The Talk concludes with tips on real use cases, webhooks, and wrapping the deployment process.
Tu Ritmo con GraphQL
GraphQL Galaxy 2022GraphQL Galaxy 2022
31 min
Tu Ritmo con GraphQL
The Talk discusses the value proposition of GraphQL and its ability to solve common pain points in API development. It highlights the importance of making informed decisions when choosing GraphQL clients, servers, and schema builders. The Talk also emphasizes the need to focus on the best developer experience in the present rather than seeking a perfect long-term solution. Additionally, it mentions the future of the Urkel GraphQL client and the reasons for dropping ReScript support. Overall, the Talk provides insights into the current state and future trends of GraphQL development.

Workshops on related topic

Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Cómo construir una animación interactiva de “Rueda de la Fortuna” con React Native
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
Cómo construir una animación interactiva de “Rueda de la Fortuna” con React Native
Top Content
Workshop
Oli Bates
Oli Bates
- Introducción - Cleo & nuestra misión- Lo que queremos construir, cómo encaja en nuestro producto & propósito, revisar los diseños- Comenzando con la configuración del entorno & “hola mundo”- Introducción a la animación de React Native- Paso 1: Hacer girar la rueda al presionar un botón- Paso 2: Arrastrar la rueda para darle velocidad- Paso 3: Agregar fricción a la rueda para frenarla- Paso 4 (extra): Agregar hápticos para una sensación inmersiva
Despliegue de aplicaciones React Native en la nube
React Summit 2023React Summit 2023
88 min
Despliegue de aplicaciones React Native en la nube
WorkshopFree
Cecelia Martinez
Cecelia Martinez
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo.
Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación.
En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Pruebas Efectivas con Detox
React Advanced 2023React Advanced 2023
159 min
Pruebas Efectivas con Detox
Workshop
Josh Justice
Josh Justice
Así que has configurado Detox para probar tu aplicación React Native. ¡Buen trabajo! Pero aún no has terminado: todavía hay muchas preguntas que necesitas responder. ¿Cuántas pruebas escribes? ¿Cuándo y dónde las ejecutas? ¿Cómo te aseguras de que hay datos de prueba disponibles? ¿Qué haces con partes de tu aplicación que utilizan APIs móviles que son difíciles de automatizar? Podrías invertir mucho esfuerzo en estas cosas, ¿vale la pena?
En esta masterclass de tres horas abordaremos estas preguntas discutiendo cómo integrar Detox en tu flujo de trabajo de desarrollo. Saldrás con las habilidades e información que necesitas para hacer de las pruebas Detox una parte natural y productiva del desarrollo diario.
Tabla de contenidos:
- Decidir qué probar con Detox vs React Native Testing Library vs pruebas manuales- Configuración de una capa de API falsa para pruebas- Cómo hacer que Detox funcione en CI en GitHub Actions de forma gratuita- Decidir cuánto de tu aplicación probar con Detox: una escala móvil- Integración de Detox en tu flujo de trabajo de desarrollo local
Prerrequisitos
- Familiaridad con la construcción de aplicaciones con React Native- Experiencia básica con Detox- Configuración de la máquina: un entorno de desarrollo CLI de React Native en funcionamiento que incluye Xcode o Android Studio
Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web
React Summit 2024React Summit 2024
92 min
Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web
WorkshopFree
Vivek Nayyar
Vivek Nayyar
Sumérgete en el mundo de la IA con nuestro masterclass interactivo diseñado específicamente para desarrolladores web. "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" ofrece una oportunidad única para cerrar la brecha entre la IA y el desarrollo web. A pesar de la prominencia de Python en el desarrollo de IA, el vasto potencial de JavaScript sigue siendo en gran medida inexplorado. Este masterclass tiene como objetivo cambiar eso.A lo largo de esta sesión práctica, los participantes aprenderán cómo aprovechar LangChain, una herramienta diseñada para hacer que los modelos de lenguaje grandes sean más accesibles y útiles, para construir agentes de IA dinámicos directamente dentro de entornos JavaScript. Este enfoque abre nuevas posibilidades para mejorar las aplicaciones web con funciones inteligentes, desde el soporte al cliente automatizado hasta la generación de contenido y más.Comenzaremos con los conceptos básicos de LangChain y los modelos de IA, asegurando una base sólida incluso para aquellos nuevos en IA. A partir de ahí, nos sumergiremos en ejercicios prácticos que demuestran cómo integrar estas tecnologías en proyectos reales de JavaScript. Los participantes trabajarán en ejemplos, enfrentando y superando los desafíos de hacer que la IA funcione sin problemas en la web.Este masterclass es más que una experiencia de aprendizaje; es una oportunidad de estar a la vanguardia de un campo emergente. Al final, los asistentes no solo habrán adquirido habilidades valiosas, sino que también habrán creado funciones mejoradas con IA que podrán llevar a sus proyectos o lugares de trabajo.Ya seas un desarrollador web experimentado curioso acerca de la IA o estés buscando expandir tus habilidades en áreas nuevas y emocionantes, "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" es tu puerta de entrada al futuro del desarrollo web. Únete a nosotros para desbloquear el potencial de la IA en tus proyectos web, haciéndolos más inteligentes, interactivos y atractivos para los usuarios.