-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LINT] Remove fix option for ESLint #2036
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point on removing this to prevent false positive in CI test. @smurching, maybe we can have a separate script for CI(lint_ci.sh)? I personally find --fix pretty useful during development.
Agree with @Zangr. I also use this script during development, and it's nice that it does in place fixing of certain style issues. Let's have a separate variant for CI which does not fix. |
I personally prefer to include lint commands into npm scripts like:
|
@harupy yes that makes sense. |
@aarondav What do you think? |
Sorry, I am not as familiar with npm -- would this mean developers would run |
You would run:
|
Sounds good, let's do it |
@aarondav , yes we need to change the CI script accordingly. |
Should I remove |
Yes, sounds good. |
Tried it out locally and it seems to work as expected, thanks for the fix! |
What changes are proposed in this pull request?
This PR propses to remove
--fix
option fromserver/js/lint.sh
(link) because with--fix
option,eslint
exits with 0 if all the detected violations are fixable. This behavior might allow code that violates the lint rules to pass the CI tests.How is this patch tested?
Tested on this PR #2035
Release Notes
Is this a user-facing change?
(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
What component(s) does this PR affect?
How should the PR be classified in the release notes? Choose one:
rn/breaking-change
- The PR will be mentioned in the "Breaking Changes" sectionrn/none
- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/feature
- A new user-facing feature worth mentioning in the release notesrn/bug-fix
- A user-facing bug fix worth mentioning in the release notesrn/documentation
- A user-facing documentation change worth mentioning in the release notes