So for the above issue:
I would like to allow us more flexibility on adding warnings for configuration or UX issues as semver-minor changes. Long-term, we need to be able to do this without having any impact on the exit code for the ESLint process.
More background can be found in the initial issue post. Also, this is currently blocking eslint/rfcs#34.
Long-term, we should probably fix this by creating a new location in the lint result object for lint run-level issues (e.g., configuration issues). Short-term, I would like to ask the TSC to consider allowing exceptions to the semver rules, on a case-by-case basis, for specific proposals in which the value of adding warnings is high enough to potentially justify breaking the users' build on semver-minor releases (especially if ESLint is already currently not working for the use case in question and we want to improve the UX and help users fix their issue). The process would be to nominate the issue on the TSC Agenda and ask the TSC to decide if the proposal should be accepted while adding warnings on a semver-minor release.
This process change would be captured in the Maintainer Guide.
Should we adopt a policy to allow, on a case-by-case basis, TSC discussion on issues that add warnings and whether they could be allowed in a semver-minor release?
I'll go ahead and note that, for RFC 34 itself, I'm thinking the whole thing is becoming more trouble than it's worth and I'd rather encourage a new CLI option or a new tool in order to let people check for potential wrong comments.
I'm still :+1: to a TSC policy change for deciding to allow more warnings on semver-minor releases in specific cases.
@kaicataldo Quoting from the initial post of that issue:
- Long-term approach: Augment the lint result object to contain a top-level property for general lint run issues (including, but not limited to, configuration issues). This would contain warnings and errors arrays. Any errors in this object would result in exit code being nonzero (same as file-level errors, including rule errors). However, any warnings in this object would not result in exit code being nonzero.
--max-warningswould not look at the warnings in this object-- it would only look at file-level warnings (ideally just rule warnings).
I would want to develop that more fully in an RFC, of course, but that's the general idea.