6 ms·

Did they change an option to disable lineWidth? In 1.* it was not possible, which was my single biggest issue with Prettier. Many times it made code less cohere

by stared 7y ago

Did they change an option to disable lineWidth? In 1.* it was not possible, which was my single biggest issue with Prettier. Many times it made code less coherent, due to forcing a few lines to be collapsed into one. See Prettier example in ESLint section of "How I Learned to Stop Worrying and Love the Types & Tests", https://p.migdal.pl/2020/03/02/types-tests-typescript.html#eslint https://p.migdal.pl/2020/03/02/types-tests-typescript.html#e....

hombre_fatal 7y ago
Why not just change it to a high value? Or prettier-ignore exceptional lines?
- stared 7y ago
  Then it wraps longer statements into one line. Which for things of unrestricted length (e.g. arrays) is not an option.
- 11235813213455 7y ago
  if you put a high lineWidth value, you'll have your object literals or destructuring mostly one-lined, etc.. often not desirable (for 4+ props) That's mostly why I don't like prettier, sometimes you want a bit of control over code formatting when several options are possible, prettier don't allow it. I use vscode formatter (actually it's TypeScript compiler formatter) instead Other things I dislike with prettier, like how it'd force parenthesis in a `2 + 3 * 4` expression, where it's a bit superfluous. Or string templates line returns on expressions https://github.com/prettier/prettier/issues/3280 https://github.com/prettier/prettier/issues/3280
  - tomduncalf 7y ago
    I felt the same at first but I’ve honestly found after about a year of using prettier on every project that you just get used to the way it formats stuff and it’s a non-issue 99% of the time. Where it does do something awkward e.g. to long expressions with lots of operators in, usually it’s actually a sign that you can make it clearer by splitting it into multiple smaller expressions which helps overall readability. I think you can also tell prettier to ignore certain lines, though I don’t think I’ve ever needed to.
  - Hurtak 7y ago
    You can controll the formatting with empty comments eg, if you dont like const {a, b, c} = props; you can do const { // a, b, c } = props;
    - monkpit 7y ago
      But please don’t.
j-f1 7y ago
This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit. We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.
jchook 7y ago
I’ve learned that the benefit of Prettier outweighs its cost in this regard. At first I disliked things about Prettier. For example, indents violate eslint’s “indent” rule with multiline ternary alignment. However, I just turned off those eslint rules and stopped worrying about it b/c Prettier’s format is “good enough” and saves me a ton of keystrokes.

by stared 7y ago

hombre_fatal 7y ago

Why not just change it to a high value? Or prettier-ignore exceptional lines?

stared 7y ago
Then it wraps longer statements into one line. Which for things of unrestricted length (e.g. arrays) is not an option.
11235813213455 7y ago
if you put a high lineWidth value, you'll have your object literals or destructuring mostly one-lined, etc.. often not desirable (for 4+ props) That's mostly why I don't like prettier, sometimes you want a bit of control over code formatting when several options are possible, prettier don't allow it. I use vscode formatter (actually it's TypeScript compiler formatter) instead Other things I dislike with prettier, like how it'd force parenthesis in a `2 + 3 * 4` expression, where it's a bit superfluous. Or string templates line returns on expressions https://github.com/prettier/prettier/issues/3280 https://github.com/prettier/prettier/issues/3280
- tomduncalf 7y ago
  I felt the same at first but I’ve honestly found after about a year of using prettier on every project that you just get used to the way it formats stuff and it’s a non-issue 99% of the time. Where it does do something awkward e.g. to long expressions with lots of operators in, usually it’s actually a sign that you can make it clearer by splitting it into multiple smaller expressions which helps overall readability. I think you can also tell prettier to ignore certain lines, though I don’t think I’ve ever needed to.
- Hurtak 7y ago
  You can controll the formatting with empty comments eg, if you dont like const {a, b, c} = props; you can do const { // a, b, c } = props;
  - monkpit 7y ago
    But please don’t.

j-f1 7y ago

This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit. We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.

jchook 7y ago

I’ve learned that the benefit of Prettier outweighs its cost in this regard. At first I disliked things about Prettier. For example, indents violate eslint’s “indent” rule with multiline ternary alignment. However, I just turned off those eslint rules and stopped worrying about it b/c Prettier’s format is “good enough” and saves me a ton of keystrokes.