-
Notifications
You must be signed in to change notification settings - Fork 14
Description
User story
The main advantage of integrating @code-pushup/eslint-plugin is that it allows setting a strict aspirational eslint.config.js, even though the current codebase isn't prepared to meet those standards. This gives users the opportunity to upgrade their ESLint config with a recommended set of strict rules. And we can suggest they include our @code-pushup/eslint-config package for this purpose.
Because @code-pushup/eslint-config supports a variety of different setups based on the user's tech stack, we should further prompt the user to select a subset of configs (the defaults may be inferred from their dependencies). Finally, we can modify their eslint.config.js and install missing ESLint plugins.
In fact, if the user has no ESLint config yet, we can create a full working configuration with @code-pushup/eslint-config.
Acceptance criteria
- The user is prompted (or provides a CLI argument) to opt in to using
@code-pushup/eslint-config. - The config setup logic is reused from the
@code-pushup/create-eslint-configpackage - see Reusable setup wizard for@code-pushup/eslint-configeslint-config#45.- If they already have an
eslint.config.js, then it is extended. - If they don't have an
eslint.config.jsyet, a new one is created. - The user is prompted (or provides a CLI argument) for a subset of configs to include.
- The default selection is inferred from which packages the user has installed.
- If they already have an
- Once the user opts in to using
@code-pushup/eslint-config, we follow up with a prompt to disable failing rules (Disable failing ESLint rules in setup wizard #1260). In this case, the default is yes.