New: Array Config

[mysticatea]

Rendered RFC

This was separated from #13.

Summary

This proposal makes .eslintrc files allowing an array as the top-level config. This is a syntax sugar of extends property and overrides property to make configuration simpler. Also, this form is closer to ESLint internal structure about configuration (ConfigArray).

Related Issues

• Config File Simplification #9
• Update: Config File Improvements #13

[not-an-aardvark]

Thanks for working on this RFC!

I don't feel strongly either way, but I'm unsure about how useful this would actually be for users. It's not clear to me that users would find array configs less confusing than extends/overrides, even if they're conceptually similar. (Array configs might seem intuitive to us because we're familiar with the internals, but for new users it might not be obvious that overrides blocks can be implemented as a series of configs that extend each other.)

---

Also, it seems like users could accidentally create an error by doing something like this:

// ./.eslintrc.js

module.exports = [
  require('eslint-config-foo'),
  { /* additional config */ }
];

// ./node_modules/eslint-config-foo/index.js

module.exports = {
  parser: 'my-parser'
};

// ./node_modules/eslint-config-foo/node_modules/my-parser/index.js

module.exports = { /* (parser implementation) */ };

In this case, the end user's array config could appear to work at first, but it would break if the shareable config started to depend on relative paths.

[mysticatea]

Yeah, actually, I don't feel strongly, too.

A use case I thought is to address conflicted localPlugins. (https://github.com/eslint/rfcs/blob/eslintrc-improvements/designs/2019-eslintrc-improvements/minor-03-plugin-renaming.md#using-two-shareable-configs-which-have-the-same-plugin-id-with-renaming) ... sorry for not linked.

[ExE-Boss]

This would bring .eslintrc closer to the upcoming eslint.config.js (#9).

[mysticatea]

Actually, I'm still opposing #9 because that's fragile and we don't need to break all users' configs completely.

[ljharb]

Array config seems like it’d make migration to the more powerful object form painful; whereas the initial pain of using an object (when this RFC would allow an array) is minimal.

[not-an-aardvark]

@ljharb I think the array form is as powerful as the object form, so it doesn't seem like a migration of that kind would be necessary. (Object configs are processed internally by compiling them into something resembling the array configs from this proposal.)

[ExE-Boss]

Array configs would also make migration to eslint.config.js (#9) easier.

Once that gets implemented at some unknown point in the future.

[mysticatea]

@ExE-Boss please mind that we have not decided to go with #9. We should evaluate this proposal as separated from that.

[ExE-Boss]

I’m keeping that in mind, that’s why I said at some unknown point in the future when the decision about #9 actually gets made.

[not-an-aardvark]

I don't feel strongly about it, but I'm leaning against supporting this RFC because it's not clear that allowing array configs would be useful, and it might lead to some confusion (by having another way to do things).

[btmills]

Thank you all for the discussion in this thread and particularly @mysticatea for putting the RFC together! Now that we've decided on a direction to take configs going forward in #9, the TSC decided today to close the other config-related RFCs so we can focus on the new format. You can follow along with that implementation work at eslint/eslint#13481.