introduces prettier for automatic code formatting

[capaj]

codebase was formatted pretty nicely even before, but it helps not having to do it manually

[coveralls]

Coverage decreased (-0.09%) to 95.715% when pulling 2ff1d22 on capaj:prettier into d93d18e on Vincit:master.

[elhigu]

If I would be paranoid, I would actually just take in the code for setting up the prettier and run the formatter myself to be sure that there was no extra code changes slipped in along the formatting changes :) No offense meant to @capaj I'm just generally not trusting anyone in the net 😬

[capaj]

@elhigu definitely. I'd be paranoid as well. You can do very nasty things in a few obcuscated lines of JS.
Feel free to take just changes to package.json and prettierrc and run prettier yourself.

[oliviertassinari]

I'm happy to see this change, it will make digging into the source code easier 👍 .

[koskimas]

@oliviertassinari I agree that this is a good change because it enforces a single style but the changes seem pretty minimal to me. How does this make the code more readable?

[oliviertassinari]

@koskimas I'm using prettier on all my projects. I'm simply used to the way it's formatting the source code, e.g. Material-UI. Hence, it's more intuitive to me.

[koskimas]

@capaj I have never used git hooks. Is there no way to add them to the repo so that they get installed to everyone that clone objection? I don't see the hooks in the PR (or am I just blind?). If there is no way to enforce the use of prettier, I think its usefulness is minimal.

[oliviertassinari]

Is there no way to add them to the repo so that they get installed to everyone that clone objection?

@koskimas prettier can be installed as a dev dependency, run on the CI and with a package script so everybody can just run it to make the CI pass.

[capaj]

Git hooks get set up by husky once you npm install. Husky is quite handy like that.

[capaj]

Also this is not just about readability. I see the main benefit in the automatic formatting. Every contributor can write code as they are used to and it gets automatically formatted. That's the most important part for me.

[einnjo]

I would advise against using the lint-staged script:

+  "lint-staged": {
+    "*.{js,json}": ["prettier --write", "git add"]

This can lead to bad commits when staging partial files (hunks). I just got bit by this in one my projects. stage a hunk in a file -> commit -> lint-staged prettifies the file belonging to the hunk and restages the WHOLE file i.e. all hunks in the file are staged and commited. It's not an easy problem to fix, see: lint-staged/lint-staged#62

I would instead suggest using the prettier plugins for eslint and a single precommit: npm run eslint hook. This way contributors will still be reminded to prettify their code before commiting posibly via a npm run prettify command.

[koskimas]

@capaj I've been testing things with prettier and I generally like its style, but one thing really bugs me: prettier tries to put everything on one line when it can. This becomes ugly with chained method calls that objection uses a lot. For example:

Person
  .query()
  .where('a', '<', 2)
  .where('b', 4)
  .eager('foo')

Becomes

Person.query().where('a', '<', 2).where('b', 4).eager('foo');

"new line per method call" style is better with github diffs too. You actually see the changed method call and not just that something in the chain changed.

Changing printWidth doesn't fix this. If we use small enough printWidth to make chaining work, everything else becomes a mess. Is there no way to make prettier work better with method chaining?

[koskimas]

Actually I was wrong. prettier does break the calls on separate lines if there are three or more method calls. I'd like it to do that after two calls, but maybe I can live with three.

[capaj]

@koskimas I will check up on prettier team if they'd consider the maximum number of calls per line as a new config. I'd personally prefer at most 2 calls per line as well.

[mceachen]

@koskimas I agree, and felt the same way a couple months ago when I started using prettier.

I have since chosen not to care, in deference to having everything be consistent and not worrying about line wrapping.

@capaj I suggest you revert most of this PR, and only add the prettier config. @elhigu or @koskimas can then produce the subsequent diffs.

[koskimas]

@juanjoLenero's point about partial files is a good one. I use git add -p and stage hunks all the time. We shouldn't use lint-staged.

[mceachen]

if you want to add a "lint" script, that'd be nice, but I think precommit is going to be a PITA.

I'd +1 the following:

  "prettier": "prettier --write",

[mceachen]

No thanks to adding lint-staged and husky deps, especially given @koskimas git-hunk commit flow.

[koskimas]

I think will go with npm run prettier and npm run eslint scripts and eslint-prettier plugin. I'll add npm run eslint to the test command. There is the npm run test-fast script that can be used while developing that doesn't run eslint. All things considered, I think this is the best compromise.

[koskimas]

Done 17e58bb

[kswope]

You murdered all your padded blocks; sorry but that is not more readable. I don't understand this cult of prettier.

[elhigu]

@kswope you have any better alternatives in mind?

[kswope]

I just use jsbeautify, but that's just for the elderly it seems

There's a thread here about using prettier but keeping the padded blocks
prettier/prettier#2352

I don't know why they refuse to add a padded blocks option, I feel like they are trolling everybody.

[elhigu]

I had never heard about that before, need to check it out. I haven't seen any js/ts auto formatter yet to whose output I would have been completely happy with.

EDIT: Looks like I wouldn't be happy with jsbeautify either beautifier/js-beautify#1064

[elhigu]

Anyways I don't think that this pull request is a good place to keep on discussion about different code formatters.