{LINTER_PREFIX}_ENABLED configs for more flexible extension of (base) configs

[pjungermann]

Is your feature request related to a problem? Please describe.
Assuming, you have a base configuration that is used by a lot of different repositories (e.g., as an organization). At each repository, you have customizations specific to this repository.

Additionally, you could consider having different base configs per flavor and a root config for these, etc.

For these cases, you can use EXTENDS to extend another config. Each key you provide at your local config will overwrite the config value from the extended config(s). Configs are extended in order and the same overwrites get applied.

At the MegaLinter config, you have multiple array type config properties like ENABLE, DISABLE, ENABLE_LINTERS, DISABLE_LINTERS, and more.
When you provide a value at the extending config, you will overwrite the whole value, replacing one array with the other one.

.mega-linter-base.yml

ENABLE_LINTERS:
  - LINTER_A

.mega-linter.yml

EXTENDS: .mega-linter-base.yml
ENABLE_LINTERS:
  - LINTER_B

merged:

ENABLE_LINTERS:
  - LINTER_B

desired outcome:

ENABLE_LINTERS:
  - LINTER_A
  - LINTER_B

Esp. for the config properties related to enabling/disabling linters, this can be a challenge. It requires the extending config to be aware of the value it's overwriting as well as changes to this value over time.

E.g., if I add LINTER_C to the base config, it will not be enabled until all places overwriting ENABLE_LINTERS add it to their config as well.

Describe the solution you'd like
I propose to use linter-specific configs as an alternative to the array-typed config properties like

REPOSITORY_CHECKOV_ENABLED: true
REPOSITORY_TRIVY_ENABLED: true

instead of

ENABLE_LINTERS:
  - REPOSITORY_CHECKOV
  - REPOSITORY_TRIVY

This allows to selectively enable or disable linters at each level without fully replacing the whole configuration part.

Similarly, you could support

REPOSITORY_ENABLED: true

to enable a whole category.

Config properties like REPOSITORY_CHECKOV_ENABLED would default to the value of REPOSITORY_ENABLED.

Describe alternatives you've considered
Alternatively, extending configs need to be adjusted for every change and changes cannot be rolled out centrally.

Additional context

Other config properties?
There are more array-typed config properties like {LINTER_PREFIX}_FILE_EXTENSIONS, {LINTER_PREFIX}_FILE_NAME_REGEX, {LINTER_PREFIX}_PRE_COMMANDS, etc.

However, in contrast to the config properties above, they usually represent a value that forms a unit while at the ENABLE/DISABLE config properties, it is rather an enumeration.

What to do with the previous configuration?
I would suggest deprecating them and removing them as part of the next major release.

Until then, there needs to be a clear hierarchy to achieve deterministic outcomes.
Hereby, I would suggest giving precedence to {LINTER_PREFIX}_ENABLED over whatever is configured at ENABLE, DISABLE, ENABLE_LINTERS, and DISABLE_LINTERS and use an empty array as their default value.

[nvuillam]

The idea is interesting, but 99% of .mega-linter.yml current configs are using ENABLE , DISABLE, ENABLE_LINTERS and DISABLE_LINTERS, and do not need EXTENDS capabilities, so such update should be incremental to the current behaviour, not deprecate it :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[pjungermann]

remove stale