Breaking: allow style lints during development #82
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch the lowers all style concerns from errors to warnings. The
change allows users to focus on true development concerns-- programmer
errors and functionality instead of prettiness and whitespace
distractions prior to committing. ESLint is excellent at flagging common
JavaScript mishaps that are true bugs but when style concerns are
elevated to the same level as legitimate issues, the latter are much
more difficult to spot.
Since stylish readability is very important as soon as a commit is ready
to be reviewed and any time thereafter, upgrading clients are strongly
encouraged to specify
--max-warnings 0
in their pre-commit tests (oruse the supplied tool new to this patch, eslint-wikimedia).
Although this change in itself isn't breaking since it's lowering
severity, most clients are expected to want to change the way they
invoke ESLint to avoid unwanted style offenders creeping in.