Add support for shorthands in `extends` and `plugins`

What is the problem you’re trying to solve?

Currently, we have to repeat the stylelint-config- prefix over and over in the extends field, the same for stylelint-plugin in the plugins field.

Similarly to ESLint, it would be nice to support the absence of the prefix, as in the following example:

Before:

module.exports = {
  extends: ['stylelint-config-recommended', 'stylelint-config-prettier', 'stylelint-config-rational-order', @myorg/stylelint-config]
};

After:

module.exports = {
  extends: ['recommended', 'prettier', 'rational-order', '@myorg'],
};

Not only this makes the config file more declarative, but it also encourages the community to publish their configs/plugins with the canonical name, and then this will leverage their packages (and the whole stylelint ecosystem) popularity.

What solution would you like to see?

I would like to see support for the following shorthands, adding a require.resolve chain:

extends:

1. stylelint-config-{config}
2. {org}/stylelint-config
3. {config}

plugins:

1. stylelint-plugin-{plugin}
2. {org}/stylelint-plugin
3. {plugin}

I have implemented this same feature in Docusaurus, and I would be glad to port it to this repository too.

[jeddy3]

That’s blog post is a great read.

I start doubting if this issue’s flexible shorthand feature is really necessary

It’s not, especially if we hope to migrate to a similar flat config system in the future.

As an aside, we’re close to a flat config system as an early design decision was not to implement cascading configs. I’m glad we made this decision.

From the blog post:

In hindsight, if we had thought things through a little more, we would have removed the configuration cascade at this point. Introducing extends enabled a lot of the same use cases as the cascade, and keeping both turned out to be a mess that we would spend years trying to fix. As an aside,

[ybiquitous]

When I’ve finished reading ESLint’s blog post about its new config system, I start doubting if this issue’s flexible shorthand feature is really necessary. Because it seems to me that the increased complexity of our code base will be worse than improved usability through the new shorthand support.

What do you think regarding this opinion?