New recommended config for eslint-plugin-ember (v14) - #1217
New recommended config for eslint-plugin-ember (v14)#1217NullVoxPopuli wants to merge 5 commits into
Conversation
| > [!NOTE] | ||
| > `ember-template-lint`'s recommended preset also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214]. | ||
|
|
||
| One more addition: `ember/no-builtin-form-components` (called out for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers. |
There was a problem hiding this comment.
Do our guides and tutorial adhere to this rule? (and all the new rules?)
| 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` | ||
|
|
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.
| For the v14 upgrade itself: | ||
|
|
||
| - Newly generated apps just get the new config from the blueprint. No teaching needed. | ||
| - Existing apps upgrading to v14 will see new errors in their gjs/gts files. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.) |
There was a problem hiding this comment.
The release notes should point at eslint bulk suppressions and Lint to the Future for adopting the new rules incrementally [...]
Could we list my codemod ignore-lint-errors here and first in the list? To my knowledge, it is the only tool that explicitly supports *.{gjs,gts} files and allows end-developers to ignore errors locally (i.e. with eslint-disable-next-line).
# From the project root
pnpx ignore-lint-errors --linter eslint
|
|
||
| ## Drawbacks | ||
|
|
||
| - Existing apps get a bunch of new lint errors on upgrade. That's the point of the major (per RFC #1214), and bulk suppressions exist so that nobody has to fix them all in one PR. |
There was a problem hiding this comment.
Could we rephrase these sentences (in particular, "a bunch of new lint errors" and "That's the point of the major") so that the RFC doesn't scare off end-developers from updating?
Unless, in a production app, there were many template-lint-disable's and many templates had multiple instances of a failed lint rule, end-developers aren't likely to see many new errors.
Here, we could mention that there are a few tools to help ignore lint errors and point the reader to the section above.
3 participants
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