Leveraging Angular Prereleases To Keep Ionic In Sync

Unlike other open-source projects, Angular tries to bring a new major release at least twice a year. With each new release, Angular stands by its commitment to ensuring the upgrade process is easier every time.

In fact, we noticed recently that the Angular team was preparing for a new major release, v10. By keeping an eye on the number of RC releases, we could tell that v10 is just around the corner and knew we needed to start testing for support with our open source projects.

Our open source UI library,Ionic Framework, depends heavily on Angular. And given that our ionic/ angular package is powering roughly 20% of all the apps in both Google Play and the iOS App Stores, we think it’s pretty important for us to manage these updates in a safe and reliable way.

With that in mind, we thought it would be fun to share some insight on how we prepare and manage Angular updates — at both the app level and library level — and in turn, make sure millions of users have a great upgrade experience. So let’s dive in.

Quick overview of Ionic

If you’re not familiar with Ionic, we’re a mobile development kit for web developers. You write your apps using familiar web languages and your JavaScript framework of choice (Angular, of course), and we give you the tools to build and deploy those apps on mobile.

Now, because Ionic Framework is a library, and not the native mobile app itself, updating Ionic Framework isn’t the same as updating an app that is built with Ionic. So keep that in mind as we go ahead.

Status report!

One of the first things we look for is to ensure that everything works between major versions. Angular has always been very consistent about making sure that major releases should just work for more people, and that includes us at Ionic. The very first thing we’ll do is read through the changelog and see if anything stands out. But sometimes the quick and easiest way to find out the state of things is to just test it out in real apps.

So when we see a new RC of a major version is released, we’ll run it through our collection of testing apps. This includes features like the conference app, star track, as well as a few other internal apps. Most of the time everything works great!

There have been a few times, however, that we’ve noticed an issue in Ionic that probably existed beforehand but wasn’t obvious. This may sound like a disaster but it actually ends up being valuable for us because it means that by addressing it, we’re making Ionic even more stable, providing a better overall experience.

Once we validate things at the app level, we then take it further and look at the library level.

Updating Ionic’s internals

For Ionic itself, we take a slightly different approach to managing upgrades. Since Ionic Framework’s release cycle is different from Angular, we end up supporting a few different major versions of Angular in our package.json. Given Angular’s commitment to stability, this works really well. Currently we support a range from 8.2 to the latest 9.x. Much of this success has to do with how we use Angular internally as well as Angular’s own stability.

We also follow the best practices for libraries that are built for Angular. In doing so, we built @ionic/angular using ng-packagr, which manages all the work for a build process of an Angular library.

While we support multiple previous versions of Angular in any given Ionic release, like all good things, they must come to an end and we do eventually make a hard cut and drop support for some past versions. We make this call by looking at what our community members are reporting for their Angular usage. This typically ends up being n-1, so whatever Angular’s latest stable release, plus one version behind.

When we absolutely need a new feature/fix, we eventually make the call to build @ionic/angular against a newer version of Angular and adjust our peer dependencies.

Parting thoughts

Well here we are. We made it through another major release of Angular and as expected, we had an easy time updating Ionic for users. Hopefully this can help shed some light on why we build against certain versions of Angular, why starters sometimes have locked versions, and how we approach managing updates across a project. Given the number of apps out there that are built with Ionic and Angular, it’s important for us to get this right, or else we’ll have some upset users!

So as we prepare for version 10.0, you can be sure that we will be going through this testing process and getting ready along with you.