5 ms·

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 of

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.
- uxp8u61q 3y ago
  > Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice. Erm, that bounty was for the production of a program that behaves exactly like prettier in at least 95% of cases, as far as I understood what "prettier test suite" means.
Cthulhu_ 3y ago
To use the Go language's formatter and a saying, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." That is, you may not like the style, but it's preferable over having no tool ensuring consistent style.
- fenomas 3y ago
  Agreed, but that's a different conversation because gofmt is a lot less opinionated than prettier. Prettier goes well beyond style issues, and messes with semantics - it will add or remove parentheses in math expressions, add or remove linebreaks within lines of code, etc. If prettier worked more like gofmt I'd probably love it and have no complaints!
  - barsonme 3y ago
    > and messes with semantics - it will add or remove parentheses in math expressions Wait, so prettier rewrites code incorrectly? Aka, it’s buggy?
    - tylerchurch 3y ago
      I've never seen it be buggy, but it will often remove unnecessary parens. For example: (a * b) + (x * y) becomes a * b + x * y. This the same code, but I often use parens for semantic grouping or to be 110% sure the operator precedence is correct for a particular formula. It's not a dealbreaker, but it does remove some of the meaning I was trying to imbue on the code.
    - fenomas 3y ago
      No, by semantic information I mean information that's meaningful to humans but not to the JS engine. E.g.: // before prettier var matrix = [ 1, 0, 0, 0, 1, 0, 0, 0, 1, ] var result = (num % divisor) | bitmask // after var matrix = [1, 0, 0, 0, 1, 0, 0, 0, 1] var result = num % divisor | bitmask No difference in actual behavior, but the linebreaks and extra parens were there to indicate the developer's intent, not to affect behavior. Prettier's outlook is that this is intentional, and the developer should add "// prettier-ignore" comments to every line of code that has semantic information they want preserved.

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.
uxp8u61q 3y ago
> Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice. Erm, that bounty was for the production of a program that behaves exactly like prettier in at least 95% of cases, as far as I understood what "prettier test suite" means.

Cthulhu_ 3y ago

To use the Go language's formatter and a saying, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." That is, you may not like the style, but it's preferable over having no tool ensuring consistent style.

fenomas 3y ago
Agreed, but that's a different conversation because gofmt is a lot less opinionated than prettier. Prettier goes well beyond style issues, and messes with semantics - it will add or remove parentheses in math expressions, add or remove linebreaks within lines of code, etc. If prettier worked more like gofmt I'd probably love it and have no complaints!
- barsonme 3y ago
  > and messes with semantics - it will add or remove parentheses in math expressions Wait, so prettier rewrites code incorrectly? Aka, it’s buggy?
  - tylerchurch 3y ago
    I've never seen it be buggy, but it will often remove unnecessary parens. For example: (a * b) + (x * y) becomes a * b + x * y. This the same code, but I often use parens for semantic grouping or to be 110% sure the operator precedence is correct for a particular formula. It's not a dealbreaker, but it does remove some of the meaning I was trying to imbue on the code.
  - fenomas 3y ago
    No, by semantic information I mean information that's meaningful to humans but not to the JS engine. E.g.: // before prettier var matrix = [ 1, 0, 0, 0, 1, 0, 0, 0, 1, ] var result = (num % divisor) | bitmask // after var matrix = [1, 0, 0, 0, 1, 0, 0, 0, 1] var result = num % divisor | bitmask No difference in actual behavior, but the linebreaks and extra parens were there to indicate the developer's intent, not to affect behavior. Prettier's outlook is that this is intentional, and the developer should add "// prettier-ignore" comments to every line of code that has semantic information they want preserved.