Proposal `extends` to support loading from module with `module:foobar`

The version of ESLint you are using. No matter of the version. But v4+

The problem you want to solve. Shareable configs is awesome. But sometimes you don’t want to create separate package and seaprate repository. Consider you are creating a linter CLI and there you put both the CLI logic and the config. You want one repo and one package, but you are using the CLI only when you are on the terminal and you are relying on the eslintConfig.extends when you are on the editor.

Currently you should do eslintConfig.extends: "./node_modules/foobar/index.js". Another way would be to create monorepo (and possibly use “fixed versioning”), but it still sounds “too much” and you may not want and not like to maintain monorepos.

https://twitter.com/tunnckoCore/status/1016441022329622534

Your take on the correct solution to problem.

https://twitter.com/tunnckoCore/status/1016444573420269568

The easiest way would be if we add one more else if check here (lib/util/naming.js#L56-L58) like

if (normalizedName.startsWith('module:')) {
  normalizedName = normalizedName.slice(7)
}

It’s the same like plugin:, but only working for configs?

Not sure if there is another place to change. I’m assuming that this normalizedName is later just required?

Wanna PR?

[not-an-aardvark]

In general, even small add-ons to a design can result in significant maintenance costs in the long term. When an existing feature such as extends: has many different functionalities, it can be much more difficult to expand or refactor the design of that feature in the future while still maintaining compatibility and coherence with all existing use cases.

It also might turn out later that we misjudged the problem that we were trying to solve, so what appears to be a small feature right now might need to become much more complex in order to adequately solve the problem. Or we might have failed to consider a given aspect of a feature thoroughly and made the wrong choice about how it should behave, resulting in a confusing behavior for users that we would be unable to change without breaking compatibility.

My personal view on software library design is that adding features should not be done lightly – it should only be done when there is a very compelling motivation. I don’t think saving a few characters in this case is sufficiently compelling.

[kaicataldo]

I’m still not convinced the maintenance burden/added config complexity is worth the slight convenience of this feature, since we can already point it directly to a module as noted in the original comment.