Deprecate named inject export from @ember/service
#1001
Conversation
kategengler
changed the title
inject export from @ember/service
Co-authored-by: Katie Gengler <katie@kmg.io>
text/1001-deprecate-named-inject.md
Outdated
|
|
||
| ## Drawbacks | ||
|
|
||
| n/a |
There was a problem hiding this comment.
I'm surprised that there are no listed drawbacks here. Indeed, you can easily change this in your app code, but if this is being imported by an addon that you don't control, there will be a cliff of ember versions that a non-updated addon can be supported on.
This is probably true generally, but it seems like a low-value artificial cliff to do this just for an export alias.
I ran a code search on emberobserver.com and it gives us lots of results for this usage: 714 addons (6562 usages)
There was a problem hiding this comment.
We need better filters on emberobserver 🤔 when I was doing all the research for #1003, I found that most usages were in addons that were no longer used, updated, or not compatible with a version of ember that would even see the deprecation. Not saying that this is the case (I see the same results, btw), but I just... can't know right now -- I should see what it would take to add some more filtering to code search on emberobserver.
This is probably true generally
aye, this is every deprecation, really.
like a low-value artificial cliff to do this just for an export alias.
as an alternative, we can auto-upgrade v1 addons via ember-cli-babel -- thoughts?
v2 addons, who don't use ember-cli-babel, are either already using plain service, or can quickly update
There was a problem hiding this comment.
I added a note here on drawbacks, and I think, in doing so, I've talked myself (or you helped me talk myself) into deferring this deprecation until Ember 6.1, targeting for removal in 7.
That gives addon authors a massive support range, should they choose to do so, of 3.28 to 6.12.x, with v7 dropping inject, making any folks with 3.28 support have to either drop it (supporting 4.1 as a minimum), or adding @embroider/macros to keep support.
This also gives the addon ecosystem a year and a half to decide how they want to support inject / service throughout the entirety of the v6 series.
There was a problem hiding this comment.
If we implement deprecation staging, we can enable the deprecation sooner even if it targets 7.0.
|
|
||
| n/a | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
a reasonable alternative would be to add a lint against it in the default lint set, essentially nudging people towards not needing it 👍
There was a problem hiding this comment.
yeah, that could happen now, actually, without an RFC
| do nothing, the cost of an export alias is: | ||
| - a few extra bytes | ||
| - mental gymnastics for teaching | ||
| - "another case to cover" for tooling |
There was a problem hiding this comment.
I don't understand this comment, can you elaborate?
There was a problem hiding this comment.
When tooling tries to implement go-to-definition for services, (because we use string-based services, we have to implement this ourselves), the tool needs to know about all the potential exports (inject and service) in order to look up their usages.
It's not a lot, but it is one more thing.
And unifying on one less thing benefits simplicity of tooling implementation, as well as our learning story.
|
Discussed at RFC review at the end of FCP, agreed to merge, with the understanding that this should probably not target 6.0, it should give people more time. |
Propose deprecating named
injectRendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage), followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP