RFC: Support for ES `accessor` Decorators

[chriskrycho]

Rendered

---

Summary:

Introduce support for the ECMAScript Decorators Proposal for the key decorators which are part of Ember’s modern programming model, @service and @tracked:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking/accessor';
import { service } from '@ember/service/accessor';

export default class Example extends Component {
  @service accessor someService;
  @service('named') accessor anotherService;
  @tracked accessor someLocalState = 123;
}

We will provide new imports to support these, a codemod to migrate to the new form, and guidance for both app and addon users about how to manage the transition.

[runspired]

I think there is an alternative path here that may be more ideal in that it ought to enable the ecosystem to more rapidly convert.

• a codemod is written to transform all legacy framework and ember-data decorator usage into accessors

  • the codemod should be able to dry-run
  • it should report any legacy decorator usage it finds that is not from framework or data decorators. Note per-ember policy non-framework decorators were never guaranteed support but we can still try to be helpful
  • it should allow transforming non-framework/data decorators as well, potentially based on a mapping
  • a matching eslint rule with an autofix should be prepared (not recommended ... yet)

• a babel-transform is written to auto-convert all legacy decorators belonging to the framework and to ember-data into the new accessor pattern. Similar to the codemod, and eslint rule this should report legacy decorators that don't belong to the framework or data. Unlike the codemod / eslint rule we will error when we encounter one.

• ember-cli-babel is updated to auto-include this transform, initially behind a feature flag. Since most apps run latest or close to latest ember-cli-babel and can pick up minors like this, we're able to get most apps in the ecosystem building with the ability to switch on compat fairly quickly.

• we start flipping the switch.

Generally this will work for all v1 addons and apps. Get to a version of ember-cli-babel that supports the new decorators, turn on support, prepare non-framework/data decorators, ship it.

Where this gets a little dicey is v2-addons since while they still partially compile during app compile based on app babel config, we would want them to ship accessor versions as soon as feasible, even before apps have updated their ember-cli-babel.

For this I think we leverage ember-auto-import, which is currently responsible for their final transpilation: converting back from the stage 3 decorators when present if necessary, and doing nothing/leaving be if ember-cli-babel has been configured to use them. Generally most apps are close to latest on ember-auto-import in my experience, and have an easy time upgrading to new minors of it.

[chriskrycho]

FWIW, I am totally fine with @runspired's alternative proposal here; I definitely do not have time to rewrite or drive it at the moment, but would be happy to see this RFC rewritten with that approach instead, or to close this in favor of a newly-opened RFC with that design.

[achambers]

@ef4 Does it make sense for you to take this on as champion?

[ef4]

Yes, I can champion, I expect that will involve doing a pass through the text and changing the place to one more similar to what @runspired is describing.