Hi. My app is now using Ember v3.16.1. I tried to update it and wasted a couple of days to no result. What are the risks (security-wise?) of not updating it, say, for half a year? When is it time to update the app? May be there’s some useful links where I can learn about it more?
1 Like
Hi @hanger, great question. Upgrading can be tricky, especially in the 3.x series where there were a lot of deprecations and a lot of API changes (Octane), but it’s well worth it. Ember provides some pretty good tooling to help, and there are some strategies that may ease your pain a little bit. But first let’s start with the why.
Why upgrade?
There are a lot of reasons to upgrade and keep current but generally I find they fall into a few buckets:
- security: keeping on LTS releases helps guarantee security patches and bugfixes. If you fall behind LTS you could be at risk of security vulnerabilities (see below!)
- new features: without upgrading you can’t use cool new features that can make your code cleaner, easier to maintain, and more fun to write. If your project is under active development this is a bigger deal than if it’s not.
- compatibility: if you stay on relatively modern versions of Ember you are more likely to be able to use addons, and due to the big shifts Ember is making in module/build system you will also have much better compatibility with other non-Ember libraries and tools
When to Upgrade
I think the general idea is that you’re either adopting bleeding edge releases (stable minor versions as they are released every 6 weeks) or if you don’t want to upgrade that frequently you stay on LTS releases. These receive bugfixes for 36 weeks and security updates for 54 weeks. If you are upgrade adverse I’d recommend LTS channel, but the more frequently you upgrade the smaller each upgrade tends to be so there is benefit to doing smaller incremental upgrades.
For security purposes upgrading every 6 months is fine (that’s well within the LTS timeline) however at Ember 3.16 you’re already 3.5 years behind (it was originally released Feb 2020).
If you fall too far behind the LTS track you run the risk of security issues. Front-end frameworks like Ember aren’t as risky as backend or infrastructure code in general, but there are still real security risks. In fact there was a recent-ish CVE in Ember that was patched but only back to Ember 3.24, so Ember 3.16 is vulnerable. I would recommend reading that blog post over and looking at your code for any unsafe usage of those APIs.
Upgrade Strategy
I think there are some things you can do to make upgrades smoother. A lot of this advice is anecdotal and some is community recommendations. I’ve upgraded a number of large apps from versions like 1.8 through 4.x, so I’ve seen some things. I’d recommend using the ember-cli-update command to bump blueprint versions and carefully integrate all blueprint differences.
Here are some tips, in no particular order:
- take it in baby steps: big bang upgrades seem appealing but can be problematic. Certain minor version ranges are more trouble than others. I’d recommend stepping through 1-4 versions at a time. Jumping LTS versions might work ok but if you really get stuck consider taking it in single minor version bumps. Also breaking your upgrade into a series of small PRs can be really helpful and minimize review time if you do code reviews.
- good tests are crucial: if you can’t trust your test suite you need to do a lot of manual testing to verify that you don’t have regressions, and that sucks
- upgrade addons first: probably the biggest source of issues i’ve encountered in Ember upgrades weren’t from framework code but from addons. Updating addons to the newest version you can (see individual addons for notes on support, hopefully they stick with SemVer conventions) first can help a lot.
- stick with “vanilla” patterns: the closer you adhere to conventions and “happy path” patterns and tools the less trouble you’ll have when upgrading
- be aggressive about fixing deprecations: a lot of stuff was deprecated in 3.x series, and the more aggressive you are about fixing the deprecations before trying to jump to 3.28 the easier a time you’ll have. This is good advice for upgrading in the future too. Always keep your deprecations in check if you can.
- ask for help: ask here or in discord if you get stuck, chances are someone will have some recommendations for how to proceed because we’ve mostly all been there
- use codemods: there are a lot of helpful codemods for fixing deprecations and adopting new patterns. Try them out!
4 Likes
Thought I’d mention some of the new features and tools you can look forward to as you embark on your upgrade journey:
Overhauled Build System
The legacy Ember build system predates Javascript modules and all the fancy bundlers that now exist. It’s fairly opaque and inflexible, and doesn’t support cool features like code splitting and tree shaking. Ember’s new build system, called Embroider, will allow the community to migrate off the old system and into much closer alignment with the greater Javascript ecosystem giving us access to fancy bundler features, faster builds, great DX tools like Vite, etc. This could be a massive improvement both for developer experience and end users (bundle sizes will theoretically drop a lot).
Typescript
Typescript, if you’re into that kind of thing, is now officially supported by the core framework and the tooling has improved to the point where writing a fully typed Ember app is now a first class experience.
Single File Components
Along with introducing template “strict mode” Ember will be adopting a new single file component format. I’ve been using it in some smaller side projects and it’s really fun, simpler to reason about IMO, and much easier to triangulate between Ember and other frameworks.
Router Overhaul
One of the things that’s planned AFAIK is an overhaul of the router. Ember’s router is robust and powerful but is showing a lot of signs of age. The refresh will hopefully align it more with modern patterns and tools and dovetail nicely with the build and SFC improvements.
Other DX improvements
Lots of smaller improvements, for example the introduction of plan function helpers. You can write custom template helpers without needing any of the helper(...) business and you can use the same function in javascript and a template easily and interchangeably. This is especially powerful in single file components.
2 Likes