Skip to content
This repository was archived by the owner on Nov 16, 2023. It is now read-only.

Conversation

@runofthemillgeek
Copy link
Contributor

Overview of changes

  • Removed pretty-quick, upgraded husky to latest
  • Added ESLint, extends Airbnb's JS config
  • Uses lint-staged to run linting/prettifying on precommit
  • Uses prettier-eslint-cli to run Prettify and ESLint
  • Tweaked VS Code workspace settings to prevent HTML formatting (not entirely), integrate prettier-eslint
  • Use npm run fix:all to try lint/fix all the files
  • Runs npm install before npm run serve to ensure everyone is getting hooks working

Suggestions 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:

  1. Has anyone faced issues with Prettier/ESLint when set to auto format/fix your changed files when executed? If not, is the current setup susceptible to any such issues? I'm not really well acquainted with doing so, especially when running both.
  2. A possible solution for linting and fixing HTML? Currently, there is none and that's causing inconsistencies when it is touched in different commits.
  3. Currently, HTML files are being fixed only when contributors are using editorconfig-aware editors and it is causing inconsistencies and accidental changes due to formatting. So, is there a way to fix it on precommit? (given there is no good html formatter)
  4. Should we have an npm run dev instead of npm 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

@dvdsgl
Copy link
Contributor

dvdsgl commented Jul 22, 2018

Looking great!

@runofthemillgeek
Copy link
Contributor Author

@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?

Copy link
Contributor

@ctrlaltvikas ctrlaltvikas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

Copy link
Contributor

@prichodko prichodko left a 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.

  1. 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",
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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"
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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": [
Copy link
Contributor

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.

Copy link
Contributor Author

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",
Copy link
Contributor

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.

Copy link
Contributor Author

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)

Copy link
Contributor

@prichodko prichodko Jul 23, 2018

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",
Copy link
Contributor

@prichodko prichodko Jul 23, 2018

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants