💥 [feat] Create a single nextcloud plugin with all the nextcloud-related rules instead of many few-rules plugins

[ShGKme]

Problem

The plugins we have:

• l10n with 2 rules: enforce-ellipsis and non-breaking-space + vue versions
• nextcloud with 2 rules: no-deprecations and no-removed-api
• nextcloud-vue with 2 rules: no-deprecated-exports and no-deprecated-props
• import-extensions with a single rule: extensions

All the plugins are, in fact, only small rule sets. They add nothing except for rules.

It increases the project file structure complexity, extra abstractions complexity and naming variations.
For example:

• @nextcloud/eslint-plugin plugin with JS rules is registered as @nextcloud
• @nextcloud/eslint-plugin plugin with Vue rules (same name, different rules) is registered as @nextcloud/vue
• @nextcloud/l10n-plugin plugin is registered as @nextcloud-l10n

It also means, if some project wants to use the rules without our config, it needs to register at least 3 plugins.

And then adding more rules in the same style means — we introduce more plugins (Just imagine if stylistic or Vue plugins would be split into many small plugins).

Is there anything wrapping into many small plugins help with?

(An exception could be the import-extensions plugin as it is not related to Nextcloud).

Proposal (breaking change)

Follow other projects way: provide a single plugin with all the rule definition and predefined set of rules if needed, without additional plugin abstraction.

[susnux]

At one point I was thinking about making it a mono repo for publishing the plugins independent of the config.

But I agree with your proposal - except the import-extensions where I still think it makes sense to publish that as a stand-alone plugin as others could be interested in that as well.

[ShGKme]

Changing names is a breaking change

[susnux]

Changing names is a breaking change

No it does not break the linting, like flat config vs legacy config in a technical way.
It just needs adjustment of the config if you modify it which is covered as "minor changes".

[ShGKme]

Making an incompatible change is a major change covered by Semantic versioning

It does break linting because the config itself is not valid anymore — you need to use different names for the rules in the config.

[ShGKme]

• Unlike blocked 💥 Force camelCase in Vue everywhere, including props/attrs #1219 which just produces warnings/errors during linting