Managing Migrations in Ember

This post focuses on a small area of improvement in the vast Ember ecosystem. Many other improvements have been articulated through other #emberjs2019 posts. As such, this post will focus on one topic only: migrations.

Ember has been has been making a lot of progress in realizing its technical roadmap; the pace of change is dizzying at times. Due to Ember's adherence to backwards compatibility, we're often able to incrementally migrate portions of applications and addons as features become available. This is one of Ember's super powers.

As with all super powers, these are coupled with a set of challenges. For larger applications, migrations can take an extended period of time. This can result in the 'old and the new' living together, side-by-side, in a code base for a significant period of time. Some problems that can arise are newer engineers not being sure of the correct pattern or API to employ, the codebase feeling in an in-between state for a while (giving rise to broken window syndrome), and a feeling that the code will never be 'clean', or live up to a higher standard.

I'm the Web Architect for LinkedIn's primary web application, linkedin.com. We have a very large Ember application that requires constant vigilance to maintain and move it forward. Managing migrations is a top concern for us, and while I believe Ember is the best fit for us for managing these migrations, it's not without opportunities for improvement.

To give you a sense of our scale, here are some point-in-time stats about the application we develop:

• 2 Ember applications that co-inhabit one large monorepo (desktop and mobile)
• 86 in-repo engines
• 342 in-repo addons
• ~3 deployments per day to production
• 694 all time committers
• 1063 commits in the last 30 days
• Changes over year - files changed: 107990, lines inserted: 2476558, lines deleted: 1833815

I think it's clear from the numbers above that an application of this size requires a set of tools to assist in managing migration complexity. I believe that providing these tools and migration guides should be a consideration when any changes are made to the framework that require significant steps.

Provide a Migration Section in RFCs

Ember's RFCs are an excellent way to develop broader consensus around proposed changes within the framework. RFCs provide a mechanism to make measured changes that signal a clear intent.

The template provided in the emberjs/rfcs repository is a great starting point for those authoring these proposed changes. It includes key sections that help detail important considerations when making any changes in the system, whether large or small.

One heading that I believe is missing is a "How we migrate this" section. This sections aim would be to articulate the plan to provide guidance and tooling to help Ember users manage migrations for new changes in the framework. This would also be an opportunity for individuals such as myself to rank and prioritize these changes within a larger application roadmap.

This would be a crucial piece, and in fact potentially a key differentiator, in deciding whether to chose to use Ember as the framework of choice.

Provide a Recommended Ordering of Migrations

As we've seen with the recent Ember Octane edition, we're now provided with a grouping of features that embody an edition. Those features

• Native Classes (+Decorators)
• Angle Bracket Syntax & Named Arguments
• Tracked Properties
• Modifiers
• Glimmer Components

can be migrated individually, and using different mechanisms. Providing guidance around the ordering of these migrations, and the relative complexities, would greatly assist in planning for landing these changes.

In some cases, having to consider the migration path for some of these changes may force us to consider prioritizing tooling in the form of codemods, whether small and incremental or large and all encompassing. Building these considerations into the features themselves will aid in adoption, and help reduce the half-state some applications and addons may find themselves in.

Provide Official Tooling to Assist with Migrations

As mentioned before, tooling has and will continue to become a key part of the migration story. We already use codemods heavily at LinkedIn to manage these changes within our applications and addons, and I believe by providing a set of community sanctioned codemods will be a powerful addition to the already compelling Ember story.

There's already work within the community to organize codemods into a Github org. The ember-cli/ember-cli-update is a great tool to aggregate and run multiple codemods for applications. It'd be great to see officially sanctioned codemods join this group of community developed ones to provide a robust set of migration tools for large-scale changes.

A Final Word

As someone who's managed an application that's large in size, ever changing, and incrementally evolving, having a high quality set of guides and tooling to assist in managing the rapid pace of changes would be a huge benefit to users. Additionally, it would help those evaluating the choice of front-end frameworks that they'll be using for the foreseeable future. Having this be a consideration from the RFC level down is crucial for that decision to be a made.