Roadmap planning 2022

[nzakas]

At the end of each year, the ESLint team brainstorms on what we'd like to accomplish in the upcoming year. This issue kicks off this part of the process.

What does "on the roadmap" mean? It means that someone on the team has committed to owning and completing the task during 2022. It also generally means that if that team member is unable to complete the task that another team members will finish it. Ideas without a team member's commitment may be taken up by the community. The intent of the roadmap is to publicly share everything that we have a high degree of certainty will get done and does not mean other things won't also get done.

Who can suggest ideas?

Anyone on the team can suggest something they'd like to accomplish on the project during 2022. The general rules:

• This is a brainstorming exercise -- all ideas will be considered.
• Including an idea on this issue does not mean it will end up on the roadmap, just that it will be discussed.
• If you suggest an idea, it is assumed that you are willing to commit to it. If you aren't willing to commit to it, then that should go through the normal process of opening an issue.
• This is not the place to debate whether an idea is good or bad. The next step after this process would be to open issue for individual ideas where we can discuss the details further.
• Think big! What do you wish ESLint could do that it currently doesn't?

Note: This issue is locked because it's a place for team members to add their ideas. It is done in the open to give the community insights into how the roadmap is developed. Non-team members can continue to suggest new features through the regular issue tracker.

[nzakas]

These are things already in progress that I plan on finishing in 2022:

1. Implement flat config (Implement Flat Config #13481)
2. Redesign eslint.org
3. Launch docs.eslint.org
4. Launch play.eslint.org
5. Set up eslint-community GitHub organization

Other things I would like to address and have not been started (aspirational ideas):

1. Switch ESLint repo to ESM
2. Create a <eslint-editor> web component
3. Allow async parsers
4. Allow async rules
5. Allow easier linting/fixing of non-JS languages

[aladdin-add]

a vote to parallel linting: eslint/rfcs#42

[aladdin-add]

Create a web component

not sure what's the meaning - will eslint officially support browsers?

but other points SGTM! 👍

[nzakas]

Oops, Markdown stripped the code. I fixed it. I want to create a editor component like we have on the demo page

[bmish]

I'm hoping to own and finish (pending RFC approval):

• feat!: Stricter rule test validation rfcs#84
• feat!: Require schemas and object-style rules rfcs#85
• Change Request: Enable reportUnusedDisableDirectives config option by default #15466
• Ability to print out the list of top disabled rules #14597
• Feature request: Support snapshot testing #14936

I could help with, but potentially more aspirational:

• Switch ESLint repo to ESM. I performed the recent ESM conversion for a similar linter ember-template-lint so I have some relevant experience here, but even just converting this smaller/less-complex linter took nearly a month of work affecting every file in the repo, so it's quite a large task.

[mdjermanovic]

Not sure if this qualifies for the roadmap, but I'd like to work on:

• eslint-scope: Removing deprecated properties/methods from scope analysis objects. That would clean up the code and the documentation, ~40% of members are deprecated.
• RuleTester: Some performance improvements (~10%).

[nzakas]

Another thing I think would be useful but I probably won't have the time to do: Enable typechecking via tsc in all of the repos. We have typedefs defined in JSDoc comments all throughout the repos, but since we don't test against them, we have no idea if they are out of date. If we can get this working, then we can also ship TypeScript definitions for each package.

Related: eslint/espree#530

[bmish]

@nzakas I like that idea. Building off of that, have we discussed going even further and converting any repos to TypeScript? I wonder if there are good candidates where that could be practical / especially useful.

[nzakas]

have we discussed going even further and converting any repos to TypeScript?

That's not something we're interested in doing. We use the ESLint repo to dogfood ESLint, and so we need to use all of the defaults, which means vanilla JavaScript top to bottom.

[btmills]

In the most recent TSC meeting, we agreed on this rough priority order:

1. Allow async parsers
2. Enable typechecking (via tsc and JSDoc comments) in our repos, and expose types from our npm packages
3. Switch the ESLint repo to ESM
4. Create an <eslint-editor> web component (like the editor on the demo, just portable)
5. Allow easier linting of non-JS languages (CSS, Markdown, etc.)
6. Allow async rules

[nzakas]

Closing, as we now have tracking issues for accepted tasks. Thanks @btmills