Propose adding @e18e/eslint-plugin to Ember CLI blueprints

[Copilot]

Propose @e18e/eslint-plugin in Blueprints

Rendered

Summary

Proposes adding @e18e/eslint-plugin to default app and addon blueprints. This plugin enforces modern JavaScript patterns, performance optimizations, and recommended module replacements through auto-fixable ESLint rules.

Key additions:

• Modernization rules: Array.at(), Array.includes(), Array.toReversed(), etc.
• Performance improvements: runtime optimization patterns
• Module replacements: community-preferred alternatives focused on bundle size
• JSON linting support: Enables linting of package.json files using @eslint/json

Implementation:

• Add dev dependency to app/addon blueprint package.json (latest version)
• Configure ESLint flat config with @e18e/eslint-plugin/recommended
• Include JSON linting configuration for package.json
• Similar to RFC 0114 (template-lint addon)

Approach:

• Uses recommended configuration with default settings
• No phased rollout needed
• Developers can manually remove the plugin if desired
• Documentation updates would require new pages in ember-learn/guides-source (Ember CLI Guides and Linting Guide only; no migration guides as linting is outside Ember ecosystem scope)

Drawbacks:

• Additional dependency and lint output
• More linting messages in projects with older code patterns

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 Exploring label 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

• The team believes the concepts described in the RFC should be pursued.
• The label S-Proposed is removed from the PR and the label S-Exploring is added.
• The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

• This PR has had the Final Comment Period label has been added to start the FCP
• The RFC is announced in #news-and-announcements in the Ember Discord.
• The RFC has complete prose, is well-specified and ready for implementation.
  • All sections of the RFC are filled out.
  • Any unanswered questions are outlined and expected to be answered before Ready for Release.
  • "How we teach this?" is sufficiently filled out.
• The RFC has a champion within one of the relevant teams.
• The RFC has consensus after the FCP period.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[NullVoxPopuli]

just an example -- I think we should do it this way:

import e18e from '@e18e/eslint-plugin';
import json from '@eslint/json';
import {defineConfig} from 'eslint/config';

export default defineConfig([
  {
    files: ['package.json'],
    language: 'json/json',
    plugins: {
      e18e,
      json
    },
    extends: ['e18e/recommended'],
  }
]);

this also implies json formatting... which I don't think wee have.

should do an RFC for just propsing a new total config? or do we RFC each change?

json formatting is pretty essential 🤔

they say,

Some rules (e.g. ban-dependencies) can be used against your package.json.

[Copilot]

Updated the configuration example to include JSON linting support with @eslint/json as suggested (commit d441940)

[NullVoxPopuli]

@copilot any documentation update here would require new pages, because I don't think we explain our approach to linting anywhere?
this would be in the ember-learn/guides-source repo if it exists.

These would be good docs to have -- but who would write them? 😉

[Copilot]

Updated the documentation section to note that new pages in ember-learn/guides-source would be needed but are outside the scope of this RFC (commit d441940)