4 ms·

Interestingly, prettier just made a breaking change in a patch release and refused to undo it for a week or so, until a particularly silly pedantic argument won

Interestingly, prettier just made a breaking change in a patch release and refused to undo it for a week or so, until a particularly silly pedantic argument won them over. https://github.com/prettier/prettier/issues/15942 https://github.com/prettier/prettier/issues/15942 My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)

oreilles 3y ago
How can a person that introduces breaking changes in patch release and then just says everyone to piss off when facing critics (just because mister "has needs for this": https://github.com/prettier/prettier/issues/15553#issuecomment-1783252676 https://github.com/prettier/prettier/issues/15553#issuecomme...) be a maintainer of such a widespread tool ?
- PufPufPuf 3y ago
  Because it's an unpaid job and the only required qualification is willing to do it.
- madeofpalk 3y ago
  What's wrong with having a need for a feature and wanting it implemented?
conaclos 3y ago
> My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff) Ruff is based on the same foundations that Biome (https://biomejs.dev/ https://biomejs.dev/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.
donatj 3y ago
I don’t see this as a breaking change. Period. The tsconfig.json files tsc itself generates and parse are definitionally JSONC. TypeScript config files are JSONC. TypeScript itself via `tsc --init` creates a file absolutely loaded with comments. It’s clearly the other tools that can’t handle JSONC that are the broken part. They can’t handle configs that typescript itself generates. The contract for “breaking” here isn’t between the tool and every single poorly written tool in existence. It’s between Prettier and the config file, and it’s correctly encoding the config file.
- mgraczyk 3y ago
  It was a breaking change, lots of people had to change their broken code, including me
  - donatj 3y ago
    You had to change your code because it was literally broken to begin with. It's not a "breaking change" if a library continues to do exactly what it's advertised as doing in a completely compatible way and already broken code downstream at no fault of the authors suddenly doesn't like it. Say a JPEG library added an additional and completely harmless metadata field - and then some JPEG parser explodes because it had hardcoded metadata fields. That's not a breaking change on the JPEG libraries part. That's just a bug on the parsers part.
    - mgraczyk 3y ago
      My code wasn't broken, I had a tsconfig file that was formatted by prettier and prettier removed trailing commas. Then I updated prettier without reformatting and my tests failed because prettier rejected the now-incorrectly formatted tsconfig file. Also your analogy is wrong and not what is happening here. Suppose that a JPEG encoder encoded files as png when the flag is `--filetype=unknown`. Then in a patch release the behavior changes so that "unknown" means jpeg. That's closer to what happened here.
  - silverwind 3y ago
    So, don't upgrade it until you fixed your code?
    - mgraczyk 3y ago
      Normally patch updates do not require you to fix your code but often include desirable security fixes. That is the purpose of semantic versioning.
bowsamic 3y ago
> until a particularly silly pedantic argument won them over. Which comment are you referring to? The release notes sound practical
- mgraczyk 3y ago
  https://github.com/prettier/prettier/issues/15942#issuecomment-1897670777 https://github.com/prettier/prettier/issues/15942#issuecomme... I sort of misspoke, the comment itself is not silly, just the fact that it was that point that got a resolution.
  - talkin 3y ago
    The more silly[1] comments are from the maintainer, saying you should update configs with workarounds for patch releases. 1: Suggested package: sillier.
    - bowsamic 3y ago
      I looked through some of the more commented on issues and there are a lot of instances from silly and aggressive suggestions from the maintainers. I get that they're burnt out but sadly I see this kind of thing quite often on OSS projects: people have very real concerns and reasonable suggestions, and are met with the most jaded and burnt out responses possible.
    - sph 3y ago
      "It's not my commit that it is wrong, it's the rest of the world that needs to fix their code." This is such an insane position to take for a maintainer. Don't be idealistic and silly. If you break compatibility, it is on you. No one cares that you are right. The Linus Torvalds "we do not break the user-space, ever" mantra should be a best practice for every open source programmer, and user-space in this case is "what the rest of the world is doing".
      - zelphirkalt 3y ago
        Bad initial designs then will forever doom any project, if only the project has a few users. And there are lots of bad designs in the open source world and in the programming projects world in general. Especially so in the NPM and Python ecosystems. In many widespread tools.

oreilles 3y ago

How can a person that introduces breaking changes in patch release and then just says everyone to piss off when facing critics (just because mister "has needs for this": https://github.com/prettier/prettier/issues/15553#issuecomment-1783252676 https://github.com/prettier/prettier/issues/15553#issuecomme...) be a maintainer of such a widespread tool ?

PufPufPuf 3y ago
Because it's an unpaid job and the only required qualification is willing to do it.
madeofpalk 3y ago
What's wrong with having a need for a feature and wanting it implemented?

conaclos 3y ago

> My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff) Ruff is based on the same foundations that Biome (https://biomejs.dev/ https://biomejs.dev/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.

donatj 3y ago

I don’t see this as a breaking change. Period. The tsconfig.json files tsc itself generates and parse are definitionally JSONC. TypeScript config files are JSONC. TypeScript itself via `tsc --init` creates a file absolutely loaded with comments. It’s clearly the other tools that can’t handle JSONC that are the broken part. They can’t handle configs that typescript itself generates. The contract for “breaking” here isn’t between the tool and every single poorly written tool in existence. It’s between Prettier and the config file, and it’s correctly encoding the config file.

mgraczyk 3y ago
It was a breaking change, lots of people had to change their broken code, including me
- donatj 3y ago
  You had to change your code because it was literally broken to begin with. It's not a "breaking change" if a library continues to do exactly what it's advertised as doing in a completely compatible way and already broken code downstream at no fault of the authors suddenly doesn't like it. Say a JPEG library added an additional and completely harmless metadata field - and then some JPEG parser explodes because it had hardcoded metadata fields. That's not a breaking change on the JPEG libraries part. That's just a bug on the parsers part.
  - mgraczyk 3y ago
    My code wasn't broken, I had a tsconfig file that was formatted by prettier and prettier removed trailing commas. Then I updated prettier without reformatting and my tests failed because prettier rejected the now-incorrectly formatted tsconfig file. Also your analogy is wrong and not what is happening here. Suppose that a JPEG encoder encoded files as png when the flag is `--filetype=unknown`. Then in a patch release the behavior changes so that "unknown" means jpeg. That's closer to what happened here.
- silverwind 3y ago
  So, don't upgrade it until you fixed your code?
  - mgraczyk 3y ago
    Normally patch updates do not require you to fix your code but often include desirable security fixes. That is the purpose of semantic versioning.

bowsamic 3y ago

> until a particularly silly pedantic argument won them over. Which comment are you referring to? The release notes sound practical

mgraczyk 3y ago
https://github.com/prettier/prettier/issues/15942#issuecomment-1897670777 https://github.com/prettier/prettier/issues/15942#issuecomme... I sort of misspoke, the comment itself is not silly, just the fact that it was that point that got a resolution.
- talkin 3y ago
  The more silly[1] comments are from the maintainer, saying you should update configs with workarounds for patch releases. 1: Suggested package: sillier.
  - bowsamic 3y ago
    I looked through some of the more commented on issues and there are a lot of instances from silly and aggressive suggestions from the maintainers. I get that they're burnt out but sadly I see this kind of thing quite often on OSS projects: people have very real concerns and reasonable suggestions, and are met with the most jaded and burnt out responses possible.
  - sph 3y ago
    "It's not my commit that it is wrong, it's the rest of the world that needs to fix their code." This is such an insane position to take for a maintainer. Don't be idealistic and silly. If you break compatibility, it is on you. No one cares that you are right. The Linus Torvalds "we do not break the user-space, ever" mantra should be a best practice for every open source programmer, and user-space in this case is "what the rest of the world is doing".
    - zelphirkalt 3y ago
      Bad initial designs then will forever doom any project, if only the project has a few users. And there are lots of bad designs in the open source world and in the programming projects world in general. Especially so in the NPM and Python ecosystems. In many widespread tools.