Aprovechando las preliberaciones angulares para mantener la sincronización iónica

A diferencia de otros proyectos de código abierto, Angular intenta traer una nueva versión importante al menos dos veces al año. Con cada nuevo lanzamiento, Angular mantiene su compromiso de asegurar que el proceso de actualización sea cada vez más fácil.
De hecho, hemos notado recientemente que el equipo de Angular se estaba preparando para una nueva versión principal, v10. Al mantener un ojo en el número de versiones RC, pudimos saber que la v10 está a la vuelta de la esquina y supimos que necesitábamos empezar a hacer pruebas para el soporte de nuestros proyectos de código abierto.
Nuestra biblioteca de código abierto de UI, Ionic Framework, depende en gran medida de Angular. Y dado que nuestro paquete iónico/angular está alimentando aproximadamente el 20% de todas las aplicaciones tanto de Google Play como de las iOS App Stores, creemos que es muy importante para nosotros administrar estas actualizaciones de una manera segura y confiable.
Teniendo esto en cuenta, pensamos que sería divertido compartir algunas ideas sobre cómo preparamos y administramos las actualizaciones angulares, tanto a nivel de aplicación como de biblioteca, y a su vez, asegurarnos de que millones de usuarios tengan una gran experiencia de actualización. Así que vamos a sumergirnos.

Vista general rápida de Ionic

Si no estás familiarizado con Ionic, somos un kit de desarrollo móvil para desarrolladores web. Escribes tus aplicaciones usando lenguajes web familiares y el marco de trabajo JavaScript que elijas (Angular, por supuesto), y te damos las herramientas para construir e implementar esas aplicaciones en el móvil.
Ahora bien, dado que Ionic Framework es una biblioteca, y no la aplicación móvil nativa en sí, actualizar Ionic Framework no es lo mismo que actualizar una aplicación construida con Ionic. Así que tenedlo en cuenta a medida que avanzamos.

¡Informe de situación!

Una de las primeras cosas que buscamos es asegurarnos de que todo funciona entre las versiones principales. Angular siempre ha sido muy consistente en asegurarse de que las versiones mayores sólo funcionen para más gente, y eso nos incluye a nosotros en Ionic. Lo primero que haremos será leer el registro de cambios y ver si algo destaca. Pero a veces la forma más rápida y fácil de averiguar el estado de las cosas es probarlo en aplicaciones reales.
Así que cuando veamos que se ha lanzado un nuevo RC de una versión principal, lo pasaremos por nuestra colección de aplicaciones de prueba. Esto incluye características como la aplicación de conferencia, la pista de estrellas, así como algunas otras aplicaciones internas. La mayoría de las veces todo funciona de maravilla!


Ha habido algunas veces, sin embargo, que hemos notado un problema en Iónica que probablemente existía de antemano pero no era obvio. Esto puede sonar como un desastre pero en realidad termina siendo valioso para nosotros porque significa que al abordarlo, estamos haciendo que la iónica sea aún más estable, proporcionando una mejor experiencia general.
Una vez que validamos las cosas en el nivel de aplicación, lo llevamos más lejos y miramos el nivel de biblioteca.

Actualizando los interiores de Ionic

En cuanto a Ionic en sí mismo, tomamos un enfoque ligeramente diferente para gestionar las actualizaciones. Como el ciclo de lanzamiento de Ionic Framework es diferente al de Angular, terminamos soportando unas pocas versiones mayores de Angular en nuestro paquete.json. Dado el compromiso de Angular con la estabilidad, esto funciona muy bien. Actualmente soportamos un rango desde 8.2 hasta la última 9.x. Mucho de este éxito tiene que ver con la forma en que usamos Angular internamente así como la propia estabilidad de Angular.
También seguimos las mejores prácticas para las bibliotecas que están construidas para Angular. Al hacerlo, construimos @iónica/angular usando ng-packagr, que gestiona todo el trabajo para un proceso de construcción de una biblioteca Angular.
Aunque apoyamos múltiples versiones anteriores de Angular en cualquier versión iónica dada, como todas las cosas buenas, deben llegar a su fin y eventualmente hacemos un corte duro y dejamos de apoyar algunas versiones anteriores. Hacemos esta llamada mirando lo que los miembros de nuestra comunidad están reportando para su uso de Angular. Esto típicamente termina siendo n-1, así que cualquiera que sea la última versión estable de Angular, más una versión posterior.
Cuando necesitamos absolutamente una nueva característica/arreglo, eventualmente hacemos la llamada para construir @iónica/angular contra una nueva versión de Angular y ajustar nuestras dependencias de pares.

Pensamientos de separación

Bueno, aquí estamos. Logramos otra gran publicación de Angular y como era de esperar, tuvimos una fácil actualización de Ionic para los usuarios. Esperemos que esto pueda ayudar a arrojar algo de luz sobre por qué construimos contra ciertas versiones de Angular, por qué los principiantes a veces tienen versiones bloqueadas, y cómo nos acercamos a la gestión de las actualizaciones a través de un proyecto. Dado el número de aplicaciones que existen construidas con Ionic y Angular, es importante que lo hagamos bien, o de lo contrario tendremos algunos usuarios molestos.
Así que mientras nos preparamos para la versión 10.0, pueden estar seguros de que pasaremos por este proceso de prueba y nos prepararemos junto con ustedes.

Categorías Blog