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 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
TSC Summary:
Previously, we discussed ESLint v7 schedule (note). In the schedule, we will start to merge the PRs of breaking changes after the release cycle of this weekend. However, we don't plan to make a release this weekend because we no longer make releases every two weeks.
Therefore, we should tweak the schedule.
My proposal is that we start to merge the PRs of breaking changes after the release cycle that will be started on 20 December 2019 finished. Then we will release the first alpha in January 2020.
TSC Question:
When should we start to merge the PRs of breaking changes?
Next item (same link):
TSC Summary:
Previously, we discussed about eslint/rfcs#40 (note). I emailed to @nzakas and he has inputted his insight. Then I updated eslint/rfcs#40.
I'd like to ask for reviewing again.
TSC Question:
Should we approve eslint/rfcs#40 or request more changes?