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-warnings in 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-warnings and any CLIEngine equivalent as the user bypassing our semver policy, similar to eslint: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