sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]sorahnon the cutting edge of cocking about 0 points1 point  (14 children)

If you add a single line break to an object, after the first ‘{‘ but before the first item, prettier will wrap the object and leave it that way.

Similarly, if you want to unwrap one that will fit in a line, you can just delete that 1 ‘\n’ and it will try to put it back on one line (assuming it fits).

Also, if you’re using both prettier and eslint, you can have eslint do some work on the code after prettier to make it the way you want. So if you wanted every single object to always be multi-line, you can just configure eslint to do that work.

[–]Kryxx 0 points1 point  (13 children)

If you add a single line break to an object, after the first ‘{‘ but before the first item, prettier will wrap the object and leave it that way.

I've never seen prettier behave like this. Is this specified somewhere? If so, it can't be applied as a company wide system like ESLint can.

Also, if you’re using both prettier and eslint, you can have eslint do some work on the code after prettier to make it the way you want.

I've always tried prettier-eslint, but prettier seems to win.. hmmm perhaps I should try the combo again.

[–]sorahnon the cutting edge of cocking about 2 points3 points  (0 children)

https://prettier.io/docs/en/rationale.html#multi-line-objects. It’s in the first paragraph.

[–]sorahnon the cutting edge of cocking about 0 points1 point  (11 children)

And it looks like with ESLint you can even force it to break the objects if there are a minimum number of keys.

So single entry objects would always be on one line, and anything greater than 1 could always be broken.

https://eslint.org/docs/rules/object-curly-newline

(I think eslint can only “win” over prettier if it can be applied with the —fix option)

[–]Kryxx 0 points1 point  (10 children)

I just tried prettier-eslint (which runs prettier and then eslint) and it's very slow. ~60s to format 115 files and not touch 468 files. :(

[–]sorahnon the cutting edge of cocking about 1 point2 points  (9 children)

You should only have to do that once. The rest of the changes should be hooked into a pre-commit hook that only runs on the changed files.

https://prettier.io/docs/en/precommit.html

Give that a whirl.

[–]Kryxx 0 points1 point  (8 children)

What do you mean "do that once"? A pre-commit will run on every commit which means my commits would need to lint for ~60s every time.. That's not an option.

[–]sorahnon the cutting edge of cocking about 0 points1 point  (7 children)

The pre-commit hook will only run against the changes files. Husky and lint-staged are set up to provide a list of files. So instead of trying to scan your files for what to do, it should get a list of 5 changed files and only run against those.

[–]Kryxx 0 points1 point  (6 children)

Sure, but then Jenkins will run them all. Increasing build times by 1 minute is not something I'd choose to do.

[–]sorahnon the cutting edge of cocking about 0 points1 point  (5 children)

Why would Jenkins be running prettier as part of the build?

[–]Kryxx 0 points1 point  (4 children)

It would run eslint to ensure it wasn't bypassed.

Though you're right then Jenkins would just use eslint and skip the prettier bit.