-
Notifications
You must be signed in to change notification settings - Fork 124
ESLint added, integration with prettier (need testing, suggestions) #104
base: master
Are you sure you want to change the base?
Conversation
|
Looking great! |
|
@dvdsgl Thanks. 😄 But I still wanna double/triple check whether it's working as intended. Do you have any suggestions regarding this and is Airbnb's style fine for JS? |
ctrlaltvikas
left a comment
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.
Great!
prichodko
left a comment
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.
Thanks for a PR! 😄 It adds a lot of useful things, however I would love to see some changes before landing it.
- I would love to see ESLint be concerned only about catching bugs and Prettier about formatting.
- use Prettier (not prettier-eslint-cli) and after
eslint --fix - add eslint-config-prettier to
eslint.rc
Please also see my comments in the review. Let me know if anything is not clear. 😊
| @@ -0,0 +1,8 @@ | |||
| { | |||
| "extends": "airbnb-base", | |||
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.
I would prefer simple and less opinionated eslint:recommended in this project.
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.
Also I would leave all formatting on Prettier without any ESLint overrides, so if you add https://github.com/prettier/eslint-config-prettier as next config it overrides any rules that Prettier uses.
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.
@prichodko Yeah, I think eslint:recommended would be a far less aggressive pick. Hm, I didn't pick eslint-config-prettier because it might class with Airbnb but if we're going to lean more on Prettier, then it's desirable I guess.
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.
Yeah, that's why I am trying to make a clear distinction between ESLint (catching bugs) and Prettier (code style), because it makes the whole configuration much easier.
| "serve": "live-server docs", | ||
| "prettier": "prettier", | ||
| "eslint": "eslint", | ||
| "precommit": "lint-staged" |
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.
New versions of Husky has a different configuration - https://github.com/typicode/husky#install
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.
Ah, you're right. I wonder why it still worked for me though.
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.
Probably will be deprecated in future major version bump.
| "precommit": "lint-staged" | ||
| }, | ||
| "lint-staged": { | ||
| "docs/**/*.js": [ |
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.
Lint-staged runs regex on a list of staged files, this is why *.js is enough.
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.
Roger. Will fix that.
| "lint-staged": { | ||
| "docs/**/*.js": [ | ||
| "prettier-eslint --write", | ||
| "eslint", |
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.
Please use just Prettier and leave all formatting up to it.
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.
You are suggesting it better to do ESLint -> Prettier? There are some good reasons why the opposite is better: prettier/prettier-eslint#101 (comment)
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.
Not sure if I follow, but comment you are referring to seems to be more in favour of Prettier (also see https://twitter.com/kentcdodds/status/913760103118991361?lang=en).
Let me make my position clear: I am a big fan of the value that Prettier tries to bring (as few code-style discussion as possible), leaving a space for ESLint to modify code-style could potentially open (unnecessary) discussions concerned about personal preferences.
| "start": "live-server docs", | ||
| "precommit": "pretty-quick --staged", | ||
| "prettier": "prettier" | ||
| "start": "npm install && npm run serve", |
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.
This change is unrelated to this PR and also makes start slow. It's a common habit to start server/app with npm start and waiting for installing new node_modules is unnecessary. New node_modules should be done by user when opening a project or pulling changes from a remote not on every script start.
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.
I totally agree with you on that. Only problem is, we need to ensure everyone who pulls new commits are doing npm install before carrying out their work. This is fine for project deps as that'll result in errors but dev deps — not so. For eg, installing husky adds hooks into .git/hooks/pre-commit but if someone forgot to do npm install after husky was added, they won't get the hooks — effectively bypassing the checks. This happened multiple times before when Prettier was added and some commits with incorrect styles got merged.
That's why I was wondering we do npm run dev in instead. I know the hosting provider usually takes care of doing npm install on changes and runs npm start so another npm install is unnecessary/might slow it a bit.
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.
Gotcha'.
I agree with you, that it's definitely undesirable situation (which would be usually handled on CI for example). In our case I would still prefer rejecting PR rather than make changes to scripts.
Overview of changes
precommitnpm run fix:allto try lint/fix all the filesnpm installbeforenpm run serveto ensure everyone is getting hooks workingSuggestions and Testing
I would've loved to discuss these in an issue but since there is no option to make one, I'd like to ask for help to see if this config is fine and if it works as currently configured. I don't know the extent to which the current setup can enforce the rules. Also, I have a few questions:
precommit? (given there is no good html formatter)npm run devinstead ofnpm start? We could then prolly have CLI linting messages and possibly more dev stuff happening.What do you guys think? Any suggestions? Also, I believe #55 could be merged soon and if we are planning to merge this, I hope the former gets merged first to avoid conflicts.
cc @dvdsgl