eslint v6 wish list

[aladdin-add]

In the spirit of previous wish lists, now that v5 has shipped, what big changes do we want to see in v6? We can use this issue for brainstorming and discussing ideas. For the changes we want to tackle for v6, we'll then create issues in the v6.0.0 milestone.

[not-an-aardvark]

• I'd like to improve the ergonomics of using custom rules. There are currently a few problems that add a high barrier to entry:

  • Using project-specific rules requires either creating a separate plugin package, using the --rulesdir flag and effectively breaking editor integrations, or using a hack like eslint-plugin-rulesdir. None of these options are particularly convenient.
  • Adding custom rules to a shareable config requires all users of the shareable config to manually install a plugin.

  As a result of these problems, we get significantly more pressure to add new core rules and features since it's harder for users to create their own.

• I'd like to make ESLint's config- and plugin-loading compatible with package tools like lerna, by resolving the issues described in Declaring shareable configs and plugins in package.json is unreliable #10125.

• I'd like to add native support for parallel linting (Lint multiple files in parallel [$500] #3565).

• I'd like to improve the security of our infrastructure and release operations (e.g. with Requiring 2FA for the ESLint GitHub organization #10630 and Requiring 2FA for npm publishes #10631), to reduce the likelihood of compromised accounts and malicious publishes in the future.

[platinumazure]

@not-an-aardvark Would it be worth splitting that into multiple posts, so that team members and community members could react to each individually?

[platinumazure]

I'd like to see if we could eliminate the local vs global installation problem in some way.

• Personally, I would love to see local-only installations (including working with any IDE integrations or other folks that are currently depending on global installations only).
• Ideally, I would like to see eslint-cli become the only globally installed thing and it would just have --init and not much else, and it would install everything needed and then use the local installation from there.
• Despite the above, I'm open to other options-- anything to reduce the pain point for users.

[kaicataldo]

I would love to go after parallel linting for this next major version. Feels overdue and could have a huge impact.

[jorgegonzalez]

Personally, I would love the JavaScript community to embrace TOML format configuration files more, as it is subjectively superior to both YAML and JSON configurations. ESLint could lead the community in this by supporting .eslintrc.toml files.

Some reasons why TOML is better than YAML for configuration files: https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html

Some arguments against JSON as a configuration language: https://www.lucidchart.com/techblog/2018/07/16/why-json-isnt-a-good-configuration-language/

[ilyavolodin]

Everything that's already been said before, plus I would want to revisited discussion about tags for rule metadata. I think rule findability is a very big pain for users, tags might be able to help with that a bit.

[ljharb]

AST-based autofixing

[nstepien]

I wish babel-eslint would be the default parser.

• I wish ESLint had TypeScript support out of the box, maybe via parser options. I've found typescript-eslint-parser to have minor bugs, and not all rules are compatible, though that's not a parser-specific issue.
• babel-eslint has support for upcoming syntax features like class properties. Using babel to use new syntax features is a common practice, so it's hard to use ESLint without babel-eslint.

[ljharb]

Better than babel-eslint, it'd be great if eslint could parse stage 3 features by default.

[StreetStrider]

Found this topic through search "plugin resolve". I got an issue which is described in @not-an-aardvark 's first point. Seemes that using custom configs with plugins distributed as a package is not possible, since plugin's resolves are relative to config consumer side and not config package side. So if I use custom config I must to install eslint plugins on the consumer side, breaking config package encapsulation.

I would like it to be possible to do things like

{ parser: require.resolve('babel-eslint'), }

with plugins at least in the same manner:

{ plugins: [ require.resolve('eslint-plugin-flowtype') ] }

or even better — to make resolving algorithm better, so it would not require any additional efforst from consumer.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[platinumazure]

Reopening, as this type of issue has been a source of valuable ideas for the roadmap. I've assigned this to myself to avoid auto-closure.

[silverwind]

I wish ESLint would attempt to reduce the installation size. Installing eslint right now results in 6339 files from 116 npm packages, totalling at 34 MB.

The biggest offenders are rxjs (16.3 MB) and lodash (4.8 MB). Possible solutions could be to bundle the CLI to a single file similar to how yarn does it. Also, if you're not using all of lodash, it might be wise to use their function modules.

[StreetStrider]

@silverwind unfortunately, LoDash' function modules are deprecated.

[silverwind]

@StreetStrider where did you get that from? Modules like https://www.npmjs.com/package/lodash.clonedeep are in widespread use and I see nothing about a deprecation. I see they have not been updated in a while, thought. Ideally I'd like to see ESLint to get rid of lodash entirely. 😉

Edit: I see they have apparently been "soft" deprecated, not via npm deprecate.

[StreetStrider]

@silverwind yes, soft deprecation. They will not make into next major.

[sindresorhus]

Possible solutions could be to bundle the CLI to a single file similar to how yarn does it.

The ncc package would be useful for that.

[aladdin-add]

Hopefully we can drop supporting node 6.x in eslint v6.0.0, so we can start supporting some async/await api.

[ljharb]

You can support that API already from plugins/rules/etc in the sense that async function is just a promise-returning function; you could use babel if you wanted to use the syntax - the only thing that dropping node 6 gets you is the ability for eslint itself to use the syntax without a build process.

[not-an-aardvark]

I think we should probably drop support for v6.x anyway given that it reaches EOL in April, and the major release will probably happen in April or later given how long prereleases have taken in the past.

[mysticatea]

Closing as released.