Delete HHAST linters that duplicate good HHClientLinters
fredemmott opened this issue · comments
Relates to #407 and #408 : we should try to avoid duplicating work, and also avoid raising two errors for the same semantic issue; it should be relatively rare to need to suppress two linters in the same line.
If the HHClientLinters are known bad, they should be automatically suppressed (and deleted from hh_client if they wont' be fixed).
If they're good, the HHAST linter should be deleted.
We are not affected by the BC break that this brings, but I bring it up anyway. HHClientLinter is a multi linter. If a sub rule was previously disabled for a certain path, devs would either have to:
- live without all HHClientLinter lints in that path
- live without that lint type in their code base
- supp all issues of the now active linter in that path
Something like a linterConfig setting like this would work.
"doNotRaiseErrorsFor": {"5562": [<path regexes>], "5633": [...]}It needs to be user-configurable before it's enabled in a release, but:
- that should ideally be via the existing 'disabledLinters' configuration option for consistency
- we shouldn't maintain code that duplicates built-in functionality
- we should provide good defaults even with 'all' setting.
@lexidor
We can let overrides in hhast-lint.json also support custom linterConfigs
Some users might want to not run HHClientLinters and some other linters for dependency source code, because obviously you cannot expect all the third-party libraries to update their code base immediately after a new compiler version is released.
FWIW, if people want some level of upgrade safety, they should not use all or default, and should explicitly list all linters (and hhclient lint codes) that they want enabled for their project.
This will still raise errors when bugs are fixed in linters that lead to them raising more errors.