Ember 3.27 Released
Today the Ember project is announcing release 3.27 of Ember.js, Ember Data, and Ember CLI. This is a minor version, stable release.
We're also announcing the start of the 3.28 beta cycle for all sub-projects. We encourage our community (especially addon authors) to help test beta builds and report any bugs before they are published as a stable release in six weeks' time. The ember-try addon is a great way to continuously test your projects against the latest Ember releases.
Ember.js 3.28 (again, starting beta today) is the final planned version of the 3.x release cycle, and will become an LTS release. As of the 3.28-beta being released, the main development branch of all Ember projects will become 4.0. Look for more information on Ember 4.0 here on the blog this coming week.
You can read more about our general release process with these resources:
Ember.js
Ember.js is the core framework for building ambitious web applications.
Changes in Ember.js 3.27
Ember.js 3.27 is an incremental, backwards compatible release of Ember with bug fixes, performance improvements, and deprecations.
For a full set of changes see CHANGELOG.md
.
Notable Bug Fixes
- Prior to 3.27
<:inverse>
would not always alias else blocks. This is corrected in glimmerjs/glimmer-vm#1296. - Ember.js 3.27.0 was released in early May and included several regressions. These were largely related to the changes in the glimmer VM and and the implementation of several deprecations, and have been corrected in patch releases leading up to 3.27.5.
Feature Additions
Contextual Helpers & Modifiers
For several years Ember has provided a mechanism called "contextual components". This API allows a developer to yield a component, optionally with arguments to apply, into a block.
In RFC #432 additional APIs were proposed which allow helpers and modifiers to be used in the same way.
For example the layout for a SuperForm
component might be implemented as:
// app/components/super-form.hbs
<form>
</form>
And be used as:
// app/templates/index.hbs
<SuperForm @model= as |f|>
<f.Input @name="title" />
<div class="error">This field </div>
<f.Textarea @name="body" />
<f.Submit />
</SuperForm>
These APIs open the doors for the creation of new, more powerful UI abstractions.
Deprecations
Ember 3.27 introduces the final set of deprecations targeting Ember 4.0. The newly introduced deprecations primarily impact uncommonly used APIs. As always, deprecated APIs are documented with a transition path in the deprecation guides.
Several notable deprecations added in 3.27 are:
Invoking Helpers Without Arguments and Parentheses in Named Argument Positions
In some templates, a helper passed as an argument can be treated as an invocation instead of passing the uninvoked helper as a value. For example:
<SomeComponent @arg= />
To better align helpers with how component and modifiers behave in the same setting, parenthesis are now required to cause an invocation:
<SomeComponent @arg= />
The non-param version of helper passing will pass a reference to the helper in Ember 4.0. See the deprecation guide entry for more details.
Importing Legacy Built-in Components
Historically, Ember applications have been able to import the base classes which
define <Input>
, <Textarea>
, and <LinkTo>
for reopening or subclassing. In
Ember 4.0, we intend to improve the internal implementation of those built-ins.
To allow this, we've been steadily deprecating parts of the built-in APIs
throughout the 3.x release series.
In 3.27, importing a the base classes of Ember built-ins is deprecated. In Ember 4.0 these modules will be unavailable. The specific deprecated imports are:
import Checkbox from '@ember/component/checkbox';
import Textarea from '@ember/component/text-area';
import TextField from '@ember/component/text-field';
import LinkToComponent from '@ember/routing/link-component';
Accessing these classes through other paths, like the owner interface, is also deprecated.
See the deprecation guide entry for more details and guidance on migrating away from these APIs.
Additionally, reopening these classes (for example to change the tagName
on a
<LinkTo>
) has been deprecated and will be unsupported in 4.0. See the
deprecation guide for migration strategies.
Deprecate Legacy Arguments to Built-ins
Ember's built-in components had a public interface largely defined by their implementation as classic Ember components. In order to refactor these built-ins to more modern implementations and improve their interfaces, large parts of their API is deprecated in 3.27.
These deprecations break down into two sections. First, there are arguments which are essentially setting HTML attributes or dealing with events. See this guide entry on legacy attribute arguments for a detailed list of deprecated arguments and migration paths.
Second, there is a set of arguments which were effectively leaks of the private implementation, or which no longer have a clear meaning (or usefulness) in modern application development. See this guide entry on legacy arguments for a detailed list and migration paths.
Deprecate the Ember Global
Ember has long set a property on the window
or globalThis
global so that
it can be accessed via window.Ember
, for example. This approach to using Ember
is incompatible with static analysis tools that can result in more optimized
application payloads.
In Ember 3.27, accessing the Ember
object via a non-module-import is
deprecated. Support for using Ember this way will be removed in Ember 4.0.
Instead, applications should adopt the Ember module API. This means importing
either the Ember
object or a specific API from the module API:
// Bad, deprecated
export default Ember.Component.extend({});
// Better
import Ember from 'ember';
export default Ember.Component.extend({});
// Best
import Component from '@ember/component';
export default Component.extend({});
See the deprecation guide and RFC 706 for more details and transition paths for other use cases.
Deprecate run loop and computed dot access
Using .
to access computed or run loop functions has been deprecated, such as computed.filter
.
Instead, import the value directly from the module:
// Bad, deprecated
import EmberObject, { computed } from '@ember/object';
const Tomster = EmberObject.extend({
readyForCamp: computed.and('hasTent', 'hasBackpack'),
readyForHike: computed.and('hasWalkingStick', 'hasBackpack')
})
// Good
import EmberObject from '@ember/object';
import { and } from '@ember/object/computed';
class Tomster extends EmberObject {
@and('hasTent', 'hasBackpack') readyForCamp;
@and('hasWalkingStick', 'hasBackpack') readyForHike;
}
Support for .
to access computed or run loop functions will be removed in Ember 4.0.
Further Information On Upgrade Timelines
For application maintainers who want to upgrade apps to Ember.js 4.0 on its release date, the list of deprecations in this release means their challenge is now well defined. Application maintainers should consider using the ember-cli-deprecation-workflow addon to address deprecations incrementally after upgrading to 3.27. ember-cli-deprecation-workflow 2.0 was released today in preperation for applications addressing Ember 3.x deprecations. Give us feedback in the issues on that repo.
For app maintainers who are in less of a hurry, please note that the upcoming release of Ember.js 3.28 will contain no new deprecations targeting Ember.js 4.0. Additionally, Ember.js 3.28 will be promoted to LTS on the same day Ember.js 4.0 is released.
We recommend that applications using LTS releases wait for the first LTS of Ember.js 4.x to upgrade, which will be Ember.js 4.4. Ember's 6 week release cycle means we expect there is about 44 weeks (from today) for apps upgrading from LTS-to-LTS to address 4.0-targeted deprecations before Ember.js 4.4-LTS is made available.
For more details on changes in Ember.js 3.27, please review the Ember.js 3.27.5 release page.
Ember Data
Ember Data is the official data persistence library for Ember.js applications. Ember Data's 3.27 release largely consists of compatability work with Ember.js.
For more details on changes in Ember Data 3.27, please review the Ember Data 3.27.0 release page.
Ember CLI
Ember CLI is the command line interface for managing and packaging Ember.js applications.
Upgrading Ember CLI
You may upgrade Ember CLI using the ember-cli-update
project:
npx ember-cli-update
This utility will help you to update your app or addon to the latest Ember CLI version. You will probably encounter merge conflicts, in which the default behavior is to let you resolve conflicts on your own. For more information on the ember-cli-update
project, see the GitHub README.
While it is recommended to keep Ember CLI versions in sync with Ember and Ember Data, this is not required. After updating ember-cli, you can keep your current version(s) of Ember or Ember Data by editing package.json
to revert the changes to the lines containing ember-source
and ember-data
.
Changes in Ember CLI 3.27
Ember CLI 3.27 introduces a flag for enabling Embroider (Ember CLI's new build pipeline) for new applications and addons. For example:
ember new my-app --embroider
Learn more about what Embroider offers and how to best configure it on the embroider-build/embroider repo.
For more details on changes and bugfixes in Ember CLI 3.27, see the Ember 3.27.0 changelog and Ember CLI 3.27.0 release page.
Thank You!
As a community-driven open-source project with an ambitious scope, each of these releases serves as a reminder that the Ember project would not have been possible without your continued support. We are extremely grateful to our contributors for their efforts.