Is your proposal related to a problem?
The problem itself is well-known (e.g. #3657, #2453 and probably more). There are many problems with the CI=true approach (mostly about unexpected discrepancy between local and remote build for developers who have no intimate knowledge of CI/CD or a particular build system in a project), but in this issue I want to highlight how it's a blocker for gradually introducing changes to project's ESLint rules.
Basically, imagine you'd like to introduce a new rule into your (project- or company-wide) ESLint configuration. What you'd want to do is add the rule, make it visible, but you'd definitely not want the build to fail and you'd also want to avoid fixing all the code at once automatically (code ownership, commit size and other issues) or manually (a lot of work). That's what a warning is for: you add it as an indicator of "things to come", make people aware of a potential problem when they come across a piece of code and hope that gradually the issue will be fixed over time, at which point the rule can be promoted to "error", which indeed would fail the build both locally and in CI.
The issue is that with current system, there is no alternative: setting CI=false is bound to break other things that might be dependent on knowing about CI environment (automated UI tests?), fixing every issue as soon as the rule is introduced is not feasible for large projects and might break at some point (if not technically, then socially, since a rule introduction might have been well-intended, but does more damage in the long run), disabling the rule "for now" is the same as not having it at all.
Describe the solution you'd like
Like in other mentioned issues, a setting (in package.json?) disabling upgrading warnings to errors would go a really long way.
Is your proposal related to a problem?
The problem itself is well-known (e.g. #3657, #2453 and probably more). There are many problems with the
CI=trueapproach (mostly about unexpected discrepancy between local and remote build for developers who have no intimate knowledge of CI/CD or a particular build system in a project), but in this issue I want to highlight how it's a blocker for gradually introducing changes to project's ESLint rules.Basically, imagine you'd like to introduce a new rule into your (project- or company-wide) ESLint configuration. What you'd want to do is add the rule, make it visible, but you'd definitely not want the build to fail and you'd also want to avoid fixing all the code at once automatically (code ownership, commit size and other issues) or manually (a lot of work). That's what a warning is for: you add it as an indicator of "things to come", make people aware of a potential problem when they come across a piece of code and hope that gradually the issue will be fixed over time, at which point the rule can be promoted to "error", which indeed would fail the build both locally and in CI.
The issue is that with current system, there is no alternative: setting
CI=falseis bound to break other things that might be dependent on knowing about CI environment (automated UI tests?), fixing every issue as soon as the rule is introduced is not feasible for large projects and might break at some point (if not technically, then socially, since a rule introduction might have been well-intended, but does more damage in the long run), disabling the rule "for now" is the same as not having it at all.Describe the solution you'd like
Like in other mentioned issues, a setting (in
package.json?) disabling upgrading warnings to errors would go a really long way.