Our existing superlinter config disables several linters that could certainly prove useful. This was done during publication as we migrated from the linting setup we used for the project internally, to the superlinter-based setup we're using here.
The main goal was to use as many linters as we could that matched the linting we were already doing, while avoiding the introduction of new checks (or more specifically failures) that would be a hindrance to publication. Of course since we continue to work on this post-publication we would like to continue to improve and uphold our code quality and to that end we should aim to have as few linters disabled as we think is reasonable.
This should not be a huge amount of work nor should it be particularly controversial I expect (I guess it depends on the linters in question and what they're complaining about) but we can also certainly tweak the linter config to set what we think is an appropriate set of warnings.
Our existing superlinter config disables several linters that could certainly prove useful. This was done during publication as we migrated from the linting setup we used for the project internally, to the superlinter-based setup we're using here.
The main goal was to use as many linters as we could that matched the linting we were already doing, while avoiding the introduction of new checks (or more specifically failures) that would be a hindrance to publication. Of course since we continue to work on this post-publication we would like to continue to improve and uphold our code quality and to that end we should aim to have as few linters disabled as we think is reasonable.
This should not be a huge amount of work nor should it be particularly controversial I expect (I guess it depends on the linters in question and what they're complaining about) but we can also certainly tweak the linter config to set what we think is an appropriate set of warnings.