TSC Summary
This PR proposes to include the Node version when hashing the cache key, ensuring that the cache is busted when consecutive linting runs are executed with different Node versions.
TSC Question
Should we accept this?
TSC Summary
In this comment, I noted that it is currently considered a breaking change to add warnings for any reason (including outside of lint rules), because of
eslint --max-warnings=0.Our semver policy currently states that causing build errors on any enhancement should always be treated as semver-major (and this is correct and sensible). When someone is using
--max-warnings, any new warnings can cause a build error.At the same time, warnings are currently our best way of reporting non-fatal errors from core (e.g., if there are minor issues with disable comments, deprecated rules, etc.). Errors and warnings are fundamentally different: Errors change the exit code of CLI processes and generally represent issues that users must resolve, but warnings do not change the exit code of CLI processes and generally represent minor issues that users could ignore. Warnings only become issues that users must resolve if they use
--max-warningsin the CLI, and that is an opt-in decision.TSC Question
Can we consider adding new warnings in semver-minor enhancements, as long as they are only warnings? As part of this, can we consider
--max-warningsand any CLIEngine equivalent as the user bypassing our semver policy, similar toeslint:all?If not, could we design a new way to communicate to users, in such a way that RFCs which add information for users could do so without semver risks? For example:
- New message severity that can never trigger nonzero exit code even with
--max-warnings- A new report section for informational messages unrelated to per-file linting
