Is your feature request related to a problem? Please describe.
Some years ago, I wrote this issue: #2202
At that time, when a user tried to override _CLI_LINT_MODE, it gave an error, as can be seen in the code quoted by @nvuillam:
|
if config.exists(self.name + "_CLI_LINT_MODE"): |
Currently, it issues a warning:
|
if config.exists(self.request_id, self.name + "_CLI_LINT_MODE"): |
Describe the solution you'd like
It would be good to convert cli_lint_mode to cli_lint_modes: [] so that each descriptor can specifically establish which modes each linter supports.
This way, if the user's override is to a supported mode, the warning will not be displayed, and if not, the error that was originally displayed in the first version mentioned will be raised.
The bonus would be that the build.py file generates a test for each supported mode so that we can test all of this, which is not currently done, and we trust that the code of the linters that have a class and manage these modes will work.
Is your feature request related to a problem? Please describe.
Some years ago, I wrote this issue: #2202
At that time, when a user tried to override
_CLI_LINT_MODE, it gave an error, as can be seen in the code quoted by @nvuillam:megalinter/megalinter/Linter.py
Line 564 in d2b1417
Currently, it issues a warning:
megalinter/megalinter/Linter.py
Line 714 in 9b98bf5
Describe the solution you'd like
It would be good to convert
cli_lint_modetocli_lint_modes: []so that each descriptor can specifically establish which modes each linter supports.This way, if the user's override is to a supported mode, the warning will not be displayed, and if not, the error that was originally displayed in the first version mentioned will be raised.
The bonus would be that the
build.pyfile generates a test for each supported mode so that we can test all of this, which is not currently done, and we trust that the code of the linters that have a class and manage these modes will work.