Quote from the discussion:
Because I'm not sure if the
bower_componentsdirectory in subdirectories is a common use-case or not, so I have left it as-is. I think that we have three directions for this.
- We keep it as-is.
- We change it to
- We remove
/bower_components/*in favor of the
ignorePatternsproperty of configs.
In fact, the 3. is consistent with our stance -- we don't add exceptions anymore because we don't want to have the allowlist/denylist of all tools in the world.
Should we stop ignoring bower_components by default in ESLint 7.x (or a later major release)?
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?