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
> 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.
> 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.
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.
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