5 ms·

Speed is always welcome, but I just wish prettier was a little less opinionated. Specifically around line length, it will just not leave my formatting alone. I

Speed is always welcome, but I just wish prettier was a little less opinionated. Specifically around line length, it will just not leave my formatting alone. I find prettier formatted code much less readable than unformatted code, and this isn't a problem I have with other code formatters like rustfmt.

beirut_bootleg 3y ago
There's a more insidious side effect to prettier related to the line length thing which I'm not sure other commenters touched upon, and the reason I avoid opinionated formatters. Prettier will affect your diff in ways you didn't intend to. Remove a member from a destructuring assignment that brings it below the line length limit, and suddenly your diff is +1/-5 instead of 0/-1, making it slightly more difficult for your reviewer to see what the exact difference is between those 5 lines removed and 1 line added - it's not immediately clear which member was removed. You try to rewrite a previous commit to fix a typo using Git's interactive rebase, and now the next commits won't replay on top if it because Prettier decided to reformat an entire code block. Another fun thing to try with prettier: add a precommit hook that runs prettier, and then try to stage partial file changes. No thanks.
- plugin-baby 3y ago
  Reformatting in precommit is destructive.
meowtimemania 3y ago
Do you have any examples where prettier code is much less readable? I haven't really ran into that issue and have been very happy with prettier.
- deleted 3y ago
  [deleted]
- harimau777 3y ago
  Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line. For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.
  - floydnoel 3y ago
    In those situations I make use of comments to force new lines where I want them. Stupid but it works!
  - pkilgore 3y ago
    Disable it! (https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html) I do this occasionally, and especially with things like test tables. Linters/formatters are there to help in the common case, not to be some oppressive dogma.
    - hu3 3y ago
      If the fix is to disable prettier for an entire file, you're proving your parent poster point.
      - dewey 3y ago
        It doesn't have to be disabled for the whole file, you can annotate lines too as shown in the link the parent commenter shared.
        francislavoie 3y ago
        Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.
  - HellsMaddy 3y ago
    I had the same gripe, and recently tried switching to dprint. It is much less aggressive with changing where lines break, and honestly it’s a huge relief to be able to break lines wherever I think makes the code most readable. It’s also significantly faster than prettier. I’ve been very happy with it.
- mostlylurks 3y ago
  If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.
  - floydnoel 3y ago
    Add a comment anywhere in the destructuring and it will force each property onto its own line.
- nicoburns 3y ago
  A good example from further down the comment section: Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this: const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`; prettier would fix it to const foo = `aaaaaaaaaaaaaaa${ bbbbbbbbbbbbb }ccccccccccccccc${ ddddddddddd }`; Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!
  - bakkoting 3y ago
    I have a PR fixing that: https://github.com/prettier/prettier/pull/15209 https://github.com/prettier/prettier/pull/15209 Just needs another maintainer's stamp.
paulddraper 3y ago
I wish it were more opinionated. It treats new lines as significant in a lot of its formatting
- vbezhenar 3y ago
  I also don't understand their stand about curly braces. They don't add or remove them. I think they should make it uniform.
  - MalseMattie 3y ago
    There is a plugin for that: https://github.com/JoshuaKGoldberg/prettier-plugin-curly https://github.com/JoshuaKGoldberg/prettier-plugin-curly
  - paulddraper 3y ago
    That's bizarre. They add/remove parens...but not curly braces... How do you even justify that...
    - bakkoting 3y ago
      Curly braces are reflected in the AST, parens are not.
bennyg 3y ago
Have you tried the print width option: https://prettier.io/docs/en/options.html#print-width https://prettier.io/docs/en/options.html#print-width?
- nicoburns 3y ago
  Yes, but unlike most formatters where the width option is a maximum and it mostly leaves your code alone below that width, prettier will aggressively widen your code to fit if you up the print width setting. I think rustfmt will actually also widen code you have put newlines in sometimes. But it's heuristic is somehow much better than prettier's.
harimau777 3y ago
Agreed! I'd go so far as to say that we would be better off if Prettier was never created.
fenomas 3y ago
I think the real issue with prettier is that it's almost become a de facto standard. E.g. personally I don't like it at all, but do like Svelte, and Svelte's official (and AFAIK only) formatter uses prettier. Hence I use prettier for Svelte, and ditto for a few other things. So the whole "extremely opinionated, if you want configuration go somewhere else" is great in principle, when people are choosing to use the tool. But if it becomes the only option for certain swathes of users, a touch more configuration would really be appropriate.
- digging 3y ago
  Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice. Besides that, I get the impression being a universal standard is kind of a non-issue for Prettier: - If it was widespread, but highly configurable, that increases friction when switching projects, because there will be tiny formatting differences everywhere - If it was not widespread, it would not be well known, increasing friction for users entering a project where it was used
  - girvo 3y ago
    If it was widespread but slightly more configurable, how would that increase friction? It’s still always setup to run automatically and transform your input to the output. The whole point of it is you don’t have to think about its rules, just code and it will do the rest.
    - deleted 3y ago
      [deleted]
  - fenomas 3y ago
    > If it was widespread, but highly configurable, that increases friction when switching projects This is clearly not true. Far and away the single most contentious JS style issue is ASI, and prettier has a config option for it and nobody bats an eye. Ditto for the prototypical style issues of indent size and tabs/spaces. The value of prettier is enforcing a consistent style within a repo, and config options don't affect that. To the contrary, config options are part of why prettier is so popular - if they'd never added ASI then a lot of projects would never have adopted it.

beirut_bootleg 3y ago

There's a more insidious side effect to prettier related to the line length thing which I'm not sure other commenters touched upon, and the reason I avoid opinionated formatters. Prettier will affect your diff in ways you didn't intend to. Remove a member from a destructuring assignment that brings it below the line length limit, and suddenly your diff is +1/-5 instead of 0/-1, making it slightly more difficult for your reviewer to see what the exact difference is between those 5 lines removed and 1 line added - it's not immediately clear which member was removed. You try to rewrite a previous commit to fix a typo using Git's interactive rebase, and now the next commits won't replay on top if it because Prettier decided to reformat an entire code block. Another fun thing to try with prettier: add a precommit hook that runs prettier, and then try to stage partial file changes. No thanks.

plugin-baby 3y ago
Reformatting in precommit is destructive.

meowtimemania 3y ago

Do you have any examples where prettier code is much less readable? I haven't really ran into that issue and have been very happy with prettier.

deleted 3y ago
[deleted]
harimau777 3y ago
Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line. For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.
- floydnoel 3y ago
  In those situations I make use of comments to force new lines where I want them. Stupid but it works!
- pkilgore 3y ago
  Disable it! (https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html) I do this occasionally, and especially with things like test tables. Linters/formatters are there to help in the common case, not to be some oppressive dogma.
  - hu3 3y ago
    If the fix is to disable prettier for an entire file, you're proving your parent poster point.
    - dewey 3y ago
      It doesn't have to be disabled for the whole file, you can annotate lines too as shown in the link the parent commenter shared.
      - francislavoie 3y ago
        Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.
- HellsMaddy 3y ago
  I had the same gripe, and recently tried switching to dprint. It is much less aggressive with changing where lines break, and honestly it’s a huge relief to be able to break lines wherever I think makes the code most readable. It’s also significantly faster than prettier. I’ve been very happy with it.
mostlylurks 3y ago
If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.
- floydnoel 3y ago
  Add a comment anywhere in the destructuring and it will force each property onto its own line.
nicoburns 3y ago
A good example from further down the comment section: Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this: const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`; prettier would fix it to const foo = `aaaaaaaaaaaaaaa${ bbbbbbbbbbbbb }ccccccccccccccc${ ddddddddddd }`; Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!
- bakkoting 3y ago
  I have a PR fixing that: https://github.com/prettier/prettier/pull/15209 https://github.com/prettier/prettier/pull/15209 Just needs another maintainer's stamp.

paulddraper 3y ago

I wish it were more opinionated. It treats new lines as significant in a lot of its formatting

vbezhenar 3y ago
I also don't understand their stand about curly braces. They don't add or remove them. I think they should make it uniform.
- MalseMattie 3y ago
  There is a plugin for that: https://github.com/JoshuaKGoldberg/prettier-plugin-curly https://github.com/JoshuaKGoldberg/prettier-plugin-curly
- paulddraper 3y ago
  That's bizarre. They add/remove parens...but not curly braces... How do you even justify that...
  - bakkoting 3y ago
    Curly braces are reflected in the AST, parens are not.

bennyg 3y ago

Have you tried the print width option: https://prettier.io/docs/en/options.html#print-width https://prettier.io/docs/en/options.html#print-width?

nicoburns 3y ago
Yes, but unlike most formatters where the width option is a maximum and it mostly leaves your code alone below that width, prettier will aggressively widen your code to fit if you up the print width setting. I think rustfmt will actually also widen code you have put newlines in sometimes. But it's heuristic is somehow much better than prettier's.

harimau777 3y ago

Agreed! I'd go so far as to say that we would be better off if Prettier was never created.

fenomas 3y ago

I think the real issue with prettier is that it's almost become a de facto standard. E.g. personally I don't like it at all, but do like Svelte, and Svelte's official (and AFAIK only) formatter uses prettier. Hence I use prettier for Svelte, and ditto for a few other things. So the whole "extremely opinionated, if you want configuration go somewhere else" is great in principle, when people are choosing to use the tool. But if it becomes the only option for certain swathes of users, a touch more configuration would really be appropriate.

digging 3y ago
Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice. Besides that, I get the impression being a universal standard is kind of a non-issue for Prettier: - If it was widespread, but highly configurable, that increases friction when switching projects, because there will be tiny formatting differences everywhere - If it was not widespread, it would not be well known, increasing friction for users entering a project where it was used
- girvo 3y ago
  If it was widespread but slightly more configurable, how would that increase friction? It’s still always setup to run automatically and transform your input to the output. The whole point of it is you don’t have to think about its rules, just code and it will do the rest.
  - deleted 3y ago
    [deleted]
- fenomas 3y ago
  > If it was widespread, but highly configurable, that increases friction when switching projects This is clearly not true. Far and away the single most contentious JS style issue is ASI, and prettier has a config option for it and nobody bats an eye. Ditto for the prototypical style issues of indent size and tabs/spaces. The value of prettier is enforcing a consistent style within a repo, and config options don't affect that. To the contrary, config options are part of why prettier is so popular - if they'd never added ASI then a lot of projects would never have adopted it.