New recommended config for eslint-plugin-ember (v14) - #1217
Open
NullVoxPopuli wants to merge 16 commits into
Open
New recommended config for eslint-plugin-ember (v14)#1217NullVoxPopuli wants to merge 16 commits into
NullVoxPopuli wants to merge 16 commits into
Conversation
kategengler
reviewed
Aug 10, 2026
ijlee2
reviewed
Aug 14, 2026
| This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14): | ||
| - the template rules that were enabled by default in `ember-template-lint` -- those of them that are applicable to strict mode -- become enabled by default for gjs/gts files. This is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via `template-lint-migration` (the hbs config), which keeps the full `ember-template-lint` parity set | ||
| - rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended` | ||
|
|
Member
There was a problem hiding this comment.
To reduce API and maintenance cost, can we also remove non-recommended rules that were reported in the ember-template-lint repo to cause issues (and the issue is still open)?
One that I'm aware of is attribute-order, whose functionality I replaced with sort-invocations. See Background in ember-template-lint/ember-template-lint#3237 for the 3 reported issues.
Contributor
Author
There was a problem hiding this comment.
perhaps -- tho non-recommended rules could style be someone's preferred styleistic set of things
on the eslint-plugin-ember side, we haven't had much issue with keep up with PRs from folks fixing things, so I'm not sure it's that big of a deal? (hopefully)
for the near term, I'd like to keep this RFC focused on the config changes, rather than removing rules altogether.
Removing rules that aren't recommended would still be a breaking/major release, but does not need to go through RFC
ijlee2
reviewed
Aug 14, 2026
ijlee2
reviewed
Aug 14, 2026
Groups it with no-builtin-form-components under a new "Add two JS rules to recommended" section, with the motivation, drawback, and alternative that reviewers will ask about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 17, 2026
recommended carries their rules now. Records the typescript-eslint disables moving into the gts block, which does change what is linted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
v14 preview here: ember-cli/eslint-plugin-ember#2840 |
One idea per sentence, active voice, simple tenses, no dashes as punctuation, no semicolons. Facts, links, code, and the appendix lists are unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NullVoxPopuli
commented
Aug 17, 2026
The body now describes policy and points at the lists. New Appendix C for the two added JS rules, new Appendix D for the removed rules. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Not permanently. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
v14 ships `hbs` only. Updates the v14-facing references and the example import. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Appendix C now holds all 59 JS rules of the set and marks the two new ones. Appendix A records the one gjs/gts rule that has no ember-template-lint equivalent, for 88 in total. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Propose a new
recommendedconfig for eslint-plugin-ember (v14)Rendered
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