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.
> 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/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.
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.
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.
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.
Looks to me like this was a discussion that devolved into idealism and this person deftly resolved it by identifying a solution that would allow maintainers to safe face while also resolving the root issue. Don't like what's being said? Change the conversation. Great move!
This person is not just a good engineer but a solid politician.
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.
"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".
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.
The issue here is that the change was done in a patch release. You can correct your past mistakes, but you should signal incompatibilities to your users by incrementing the major version.
At least have the courtesy to bump the major version number. If you're going to break compatibility, then own it. If what you're doing is really for the best then don't try to do it quietly in shame, announce it with fanfare.
> The Linus Torvalds "we do not break the user-space, ever" mantra should be a best practice for every open source programmer
I think that has to forever live in tension with its opposite. I mean, every opensource project also lives or dies based on the volunteered time of its maintainers. If "being be idealistic and silly" is needed to keep maintainers around, then its not silly.
and to be honest, it didn't look like silly to me :) It was an interesting read for me, who as a maintainer, I tend to give more importance to the official statements such as in this case written recommendations of the source company that defined the new format.
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#issuecomme...) be a maintainer of such a widespread tool ?
I'm not sure I got an answer to the question in the title. Prettier is rock solid because it was based on a paper by someone who designed Haskell? That's a cool link, but I'm not sure what the insight is, is this evidence that functional programming-style algorithms lead to a more stable codebase?
I think prettier's initial author answered the question quite concisely in the article's first link. Title and excerpt copied below:
> Dig into past research.
> If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it.
Yeah I kinda think people are always "learning from their last mistake" (and that's definitely true for me)
- Sometimes you hack, and you end up with a mess. And then the lesson you learn is to study the prior art first.
- Sometimes you spin your wheels reading stuff that isn't actually applicable to the problem you have. Then the lesson learned is to "do the simplest thing that could work", "solve 80% of the problem with 20% of the effort", etc.
So to me, programming is really a cycle of learning, and you can't really generalize the order of doing things ... It's iterative stumbling and learning, in both orders :)
Yes - I quite often get into research paralysis where I keep looking and trying to work out the solutions to different problems I'm going to encounter and never getting started. Whereas if I start protoyping I learn a lot very quickly.
This is the way. Unfortunately this is not going to work, not in a startup environment. You probably do everything except the throwing away and re-implementing part..
Nor in any environment where a client is paying you to develop something. Try showing them an MVP and then telling them "ok, now I know how to do this I will throw it away and redo it from the beginning". Not to mention that, with unclear and constantly changing requirements, you are unlikely to ever arrive at a point where you can say that...
+1 I think there's something to be gained by just trying it your way first. Maybeyou'll come up with something new and insightful by not tainting your brain first, and if not, you will at least gain a deeper understanding of the problem space.
This isn’t actually true. Prettier does break code in strange circumstances and it can be very difficult to fix. The maintainers have a ton of stress on them and it’s hard to improve it sometimes.
It’s very well tested and easy to add cases too - just add an input and an output so that may be why it seems so solid, just whenever there is an issue people fix it.
I think the main thing is that Meta maintains it which probably is why it’s so solid.
Yeah I think having motivated and paid maintainers helps a lot. If maintaining the repo is the responsibility of a team that’s working 9 to 5, it’s much more likely that it’s going to succeed. Such a project avoids most of the pitfalls that are faced by individual open source developers coding in their spare time - lack of funding, appreciation, time, help etc. If one person in the team wants to move on, the company will find another person to take their place.
That’s possibly why React and Go and Prettier continue to flourish. While the maintainers have had a lot of hard technical problems to solve, they didn’t need to worry about making rent or burning their weekends triaging issues instead of spending time with family. Many of the original authors are no longer working on the projects, but they’ve been replaced by other Google and Meta employees. This had a bigger impact than basing Go on a paper written by a Haskeller.
All this to say - if you’re depending on open source you need to fund it directly. Dont expect that FAANG will forever, or there will be a magic wand like a research paper that makes it automatically easier to maintain.
1.1k isn't bad for a project with ~33 million weekly downloads[1], imo. Yes, I know that's not necessarily a good metric, but it's ~10 million more than React[2] which also has a similar number of open issues[3].
A code formatter has no business having 1100 open issues (5k closed). It is not rocket science.
In my experience, the number of open issues not only correlates with popularity, but how crappy the language is. Javascript projects, with its myriad of dependencies and attracting junior, inexperienced devs, tend to accumulate a great number of bugs.
For reference, curl has 24 open issues (4k closed), it is a couple orders of magnitude more complex AND more used than prettier.
I don't know enough about prettier. But in general linters (which have overlap with formatters but aren't the same) have a lot of issues that fall in the "this is not my preference. It must therefore be changed" category.
"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
I guess.
That annoys the crap out of me. Closing stale issues doesn’t make the issues go away, it just means that edge cases aren’t addressed. If I have an issue and find myself in a stale-closed issue, I’m not even going to bother reporting it. I’m either going to look for a different library altogether, one that actually tries to solve edge cases; or I’m going to create my own library as a big middle-finger to the project. At work, I’ll just open a new issue, which will probably just be ignored.
Yeah, I stopped reporting issues to projects when I have seen tons of stale bot closed issues. Those were real bugs, still really in the codebase, just no one fixed it for arbitrary short time.
And arguably we’re where we are because people have this idea that issue counts are comparable between projects.
I see this way of thinking around CVEs too. I think it’s a mistake of making data-driven decisions based on noise rather than signals. It sounds good when you have a comparative number to go on.
I see open issues as a pretty good signal that people are using the software and people care about its development, but maybe the number of contributors is too small. In these cases, I might even open the PR myself. Issues without replies though is probably the worst signal you can send as a maintainer. Closing issues without replying and letting a stale bot passively aggressively close issues is probably tied, but it’s usually hidden away.
I don’t want to post a specific issue without doxxing myself but you can browse through the open issues on GitHub to find some.
Some are years old! I think the more popular languages tend to be better supported so you probably don’t know about it but prettier is a massive monolith with support for many languages and use cases. Sometimes there are bugs that mangle code
Off topic but every once and a while I'm made aware of the impact prettier has had on my typing. It's so hard to write code without a tool like prettier because formatting related keystrokes have largely been removed from my muscle memory. You basically end up writing a sort of shorthand.
Yeah it’s true. Its not simply that you don’t have to manually format things a certain way. You simply don’t format things at all. You can avoid writing lots of spaces, newlines, semi colons, etc. it’s absolute garbage, then you save it, then it’s fine.
And autoformatters have cemented my preference for non-white spaced languages. As you say, just write whatever and let it format it. When I then switch to our python backend this strategy no longer works. Like, it can fix something, but it needs a much cleaner state to do so. For instance if my loops are indented wrong, black can't solve that as the decision it makes has a semantic meaning.
Something of a tangent: with Automatic Semicolon Insertion (ASI), JS is a white-space influenced language. Some of prettier's defaults are directly related to ASI, such as the way it often wraps things in extra ("unnecessary") parentheses, especially JSX but also anything complicated and multi-line especially after keywords like `return`. (`return` is the trickiest under ASI, so prettier's defaults seem that conservative in large part because of `return`.)
As someone who appreciates `{ "semi": false }` in my prettierrc, I take a lot of advantage of JS' ASI and find prettier's behavior interesting and conservative, but useful.
A team I'm doing some work with uses eslint and has not configured prettier, so instead of simply having everything get formatted correctly, I get red squiggly lines under blocks of code because of an omitted meaningless whitespace character.
There are a few linting rules that can help identify semantic errors or dead code, but only a small number of rules are needed to get all of the benefits.
Autoformatting (prettier, gofmt, etc.) is the way to go.
many (most?) red squiggles are autofixable with eslint. I use eslint exactly like prettier, in that I never think
about formatting and everything gets fixed/formatted on save.
Many are, but some of the "errors" are not helpful while code is in progress. Why do I need to see them while typing if they can be easily auto-fixed later? It's just more useless visual clutter to worry about.
In languages which don't use indentation semantically, I always end up catching a bug, sooner or later, by running code through a formatter. It's usually in a complex tree of nested if statements, some code I thought was part of one group gets moved to be in another group, making it obvious where the mistake was.
Python can't do that. It's one of a few things about the language which is "nice" when using it for simple tasks, but which makes more complex programming pointlessly error-prone.
But that leaves you having to manually adjust entire blocks, when indentation levels change. With {}, prettier can readjust everything properly for you, even after mutilating changes such as copying an entire block from a different file into a new one, and at a different indentation level.
Python formatters do that too, they don't care about the indentation, as long as it's consistent. All I need to do is indent the block far enough to the right that it's not more left than the previous one, and that's it.
This also happens rarely enough that it's never been an issue for me.
I find selecting a block of code and hitting tab/shift+tab much simpler and faster than hunting down matching parenthesis, especially when adjusting longer sections or complex situations.
Of course this is mostly a tooling issue, since there is a shortcut for adjusting indentation but not for adjusting parenthesis. Or maybe there is and I just haven't discovered it yet.
Yes I just started dabbling with copilot and I feel much the same as when I began really leveraging prettier.
I’m similarly surprised to see such an ingrained skill undergo such rapid change. And it’s funny because for me prettier was originally just meant to fix the chaos that is every dev having their own style/editor preferences.
I'm ~120WPM and a vim user, and yeah the main thing is how little time I actually spend typing. It helps me keep my focus on what I'm doing.
I think other tools (like the ones people are mentioning) do stuff like this for people: autocomplete, copilot, formatters, etc. I also use formatters and linters, and my autocomplete is "be strict about conventions, look up the actual meanings of words", which makes me touchy about conventions haha.
I type at 100WPM and that's usually fast enough for programming but not always. Sometimes you just know exactly what needs to be written, maybe because you've written similar things before.
I don’t do it simultaneously, when I do know what I want to code it just takes me less time writing it out so sooner I go back to thinking what’s next.
Programming is mostly thinking interspersed with a bit of typing. Nobody thinks as they type. The typing bit is just getting your abstract idea of what the program should do into the computer.
I think I probably suffer from the same thing. On top of that, I added a VS macro that adds missing imports, cleans up unused ones, and re-orders them in a single keystroke. I've never been lazier.
My complaint--and MDN and the W3C's complaint--with it is that it puts a closing slash on HTML void elements. While this is allowed for backwards compatibility with XHTML, it is not specified as being useful or needed in any HTML specification and has led to countless confusion among noobs who don't read the specification and only follow online articles.
How large are the files you're formatting? I have prettier set to format on save in vscode and even for the largest files in my codebase (>1000 lines) it formats near-instantaneously on my 2019 macbook pro. Definitely well under a second.
Ehh I would disagree here. Yes, prettier uses the classic pretty printing paper, but almost every pretty printer does in some form. And even then it’s subjective how you compile the actual syntax down to the printer elements. Prettier uses a very thick layer of complicated translation rules to get the printing just right. Especially with JSX and TypeScript. It’s honestly just good old testing and labor that makes it good. And even then I anticipate more than a few comments decrying prettier’s formatting. You can’t please everybody. That’s why it’s prettier not prettiest
I think I agree about the testing and labor of complicated translation rules.
But it doesn't appear that almost every pretty printer is based on the Wadler algorithm. It seems like MOST of them are not?
e.g. clang-format is one of the biggest and best, and it has a model that includes "unwrapped lines", a "layouter", a line break cost function, exhaustive search with memoization, and Dijikstra's algorithm:
It almost seems like there are 2 camps -- the functional algorithms for functional/expression-based languages, and other algorithms for more statement-based languages.
Though I guess Prettier/JavaScript falls on the functional side.
I just ran across this paper that includes a nice survey (on lobste.rs) and it seems to cover the functional pretty printing languages influenced by Wadler, in the functional style (e.g. for and in Racket or Haskell), but not the other kind of formatter ("Google" formatters perhaps)
> note that gofmt doesn't indent, which is the hard part
interesting because for me it's hard to read changelogs of js/ts based repos that are using prettier compared to go repos, I wonder if the indentation is a reason for that. I'm honestly not sure what the author means by that either, gofmt seems to fix indentation for me.
If you're reading a PR diff on GitHub you can get it to ignore whitespace diffs by adding ?w=1 to the url - complete lifesaver in this kind of situation.
Also, the white space diffs shouldn't be significant as long as all the files were already properly formatted before the change. If your diffs are including unrelated formatting changes, then you should do a single commit to format all your files. You can also use git-ignore-revs so that this formatting commit won't show up in git blame.
The debate for me is now eslint —-fix or prettier. I don’t get why people need more “control”. If it breaks code, then sure, I understand the reservation but in 99% of cases, it just, “I don’t like how it breaks up my code”. Why care? At least, if you’re all using it, the diffs will be predictable and PRs can focus on what matters. //rant
Or stylistic eslint community plugin which started by forking the deprecated rules/plugins. It's the most promising option IMO, since unlike prettier they're actually receptive to making changes / adding config options that will allow making code and in particular diffs, err, prettier.
Yeah the eslint stylistic plugin basically deprecated Prettier for all my purposes (+ my team just moved to it too.) I wish it could autofix line length warnings like Prettier but I understand the reasons why it doesn't and it's easy to manually fix those anyway.
I can't remember the last time PR comments addressed minor formatting issues at all, in any language. If something is hard to grok it usually has to do with logic, not if there's a space between `if` and `(`.
You're right, I more meant that if you don't format, your code sometimes becomes difficult to read and you become disincentivized to fix anything because git blame will point at you. I run into this all the time when people tell me, don't format the code because we won't know who did what. I get this even from senior devs as if using git blame and history is rocket science. If everyone stops bickering and just formats, all this noise goes away.
Do not use Prettier with HTML. We can't use Prettier at work because it doesn't reformat HTML but actually rewrites it, taking liberties to insert new closing tags where it sees fit and where they were never present before. We found this because it actually led to things breaking in practice. A code formatter should never add meaningful new code to your project which changes its behaviour and content. That's no longer a code formatter but a random bug generator.
I picked up standard[1] a while back for this reason, I don't want to have to think about it. It works fine, I have no complaints (took me a while to get used to not using semi-colons but now I prefer it) Same reason I use `cargo fmt` as well.
In JavaScript (and in TypeScript), not using the semi-colon is often a footgun.
Here's a surprise:
const a = 1
const b = 2
(a+b).toString()
Calling the convention "standard" was irresponsible, and it led many people (especially beginners) to assume that it was some sort of a preferred convention. Glad I'm seeing it less these days; thanks to TypeScript, and people following Microsoft's conventions.
There's only one "extra" rule to remember when not using semicolons: the winky frown rule. If it starts with a frown (, [, ` then it must wink: ;(, ;[, ;`
It's a silly sounding rule, but that makes it easy to remember.
The rest of Automatic Semicolon Insertion footguns happen to everyone whether they use semicolons or not, such as: do not add a newline after return, that makes it a return undefined. Semicolons won't help. (Typescript return type annotations will help.)
Related to the topic at hand, prettier configured with `{ "semi": false }` (which I prefer to standard these days because I think prettier autoformatting is, uh, prettier) in my experience catches most winky frown violations for you and auto-fixes them.
I switched to Python Black and isort for the exact same reason. It just takes all of the thinking out of it. Even better, these tools mean I don't have to teach (and police) code style. I let a pre-commit hook handle that.
The whole point of using opinionated code formatters is to offload the mental effort of forming (and enforcing) opinions to a third party, so I very purposefully rely on isort's and black's defaults.
This was said in jest but: I wouldn’t make this comment seriously. The difference here is that the authors of Java generics had to work with the hysterical raisins of pre-generics Java.
Anything rock solid has a well thought out architecture, where the author(s) have thought through the entire problem domain and edge cases. Also has a ton of test cases to verify behavior.
Prettier is rock solid but compared to rust based tools like ruff, it is dog shit slow.
I don't resonate with this. We've had a bunch of annoying issues with Prettier making code a mangled mess. It's not hard to not break code syntactically, but prettier has certainly messed things up visually before.
But I really wish gofmt gets inspired by prettier and automatically breaks long (80+ columns) lines into smaller lines (For example, move parameters of a long function each into their row).
Oh I'm curious why you're rewriting it? Maybe speed, quality, handling new language features, or all of the above? I may dive into this problem
What do you think of the functional "pretty printing languages" like Wadler's (cited in the blog post)?
It is kinda interesting that the author of prettier credits the algorithm, but other people say that it's more about labor and testing of specific style rules.
Having never written a pretty printer, it does seem like there is a lot of labor in encoding the "rules people like", and flags for different styles. And then there's the actual algorithm to find the line breaks.
Or maybe they are not really separate things. I think the more academic work is trying to separate the 2 things, but they can be fairly intertwined? (e.g. for performance reasons)
The formatter works sort of like a compiler in that it parses the code, translates it to an internal representation, does optimization on that IR, and then outputs final code. The main difference is that the "final code" is also source code, and the "optimization" is line splitting.
The old IR grew organically over time and got increasingly difficult to work with. It baked certain formatting choices directly into the IR (mainly indentation) which line splitting then had no control over. For example, given a function call like:
someLongFunctionName(some + long + argument + expression, [firstElement, anotherElement, aThirdElement]);
We might want to format it like this if the function name and first argument fits on one line:
But if the first argument doesn't fit, then we probably want:
someLongFunctionName(
some + long + argument + expression,
[
firstElement,
anotherElement,
aThirdElement
]);
Note how the indentation of the list elements depends on how we choose to line split the argument list. The old formatter's IR just couldn't model that at all.
For years, I've wanted a better IR that could express formatting like this. And since we were making sweeping changes to the formatting style (including some that would be very hard to implement with the old IR), it seemed like the right time to move to a new internal representation too.
> What do you think of the functional "pretty printing languages" like Wadler's (cited in the blog post)?
I have to confess that I worked on dartfmt for a few years before I stumbled onto that paper. I'm somewhat familiar with it, but I've never taken the time to really dig into it.
I could be wrong, but I strongly suspect that the formatting rules we want for Dart are too complex to model using Wadler's formalism directly, and I'm not sure if extending it to support the formatting rules we want would sacrifice its simplicity or performance.
Given that, I sort of stuck with the devil I already knew—dartfmt's current architecture—and built off of that.
> it does seem like there is a lot of labor in encoding the "rules people like", and flags for different styles. And then there's the actual algorithm to find the line breaks.
Yes, and the two are deeply intertwined. The majority of dartfmt's code by line count is just implementing the style rules for every part of the language grammar. The most difficult code to write and maintain in dartfmt is the line splitting algorithm, largely because it's combinatorial when done naïvely.
OK very interesting! I skimmed over the issue and some of the examples.
It does seem like there are at least two schools of thought on the pretty printers -- those influenced by the Wadler pretty printing language (functional style), and those more influenced by go fmt (which does no line wrapping) and clang-format (which does).
There's a very recent paper linked here which has a good survey of the functional style. Table 1 is a nice summary of the different algorithms and IRs, a bunch of them appearing only in the last 10 years.
I'm probably biased toward the "non-PPL" style of clang-format because I think it's the best formatter I've used. It's fast and does what I want. I would probably attribute that to all the elbow grease and testing put in over the years, and being written in C++, not necessarily the wrapping algorithm.
But now that I see the examples, my suspicion is that some of the newer IRs and algorithms do address some of the Dart problems (though I didn't try anything!). Dart seems to have long expressions very much in common with functional languages, as opposed to Go, which apparently doesn't need wrapping at all!
I found this post linked from the paper, and it has 3 examples of formatting s-expressions that seem pretty similar to your examples.
And they discuss what IR is needed to express that. They talk about greedy algorithms vs. "non-local" dependencies.
It seems like the IR of chunks, rules, and spans has a lot of similarity to what they call "groups" and so forth. Several years ago, long before I looked at any of this, I actually implemented a data structure printer with the same 2 rules as on page 2 of this paper - https://lindig.github.io/papers/strictly-pretty-2000.pdf
i.e. try to fit all the parts on a single line, and if that fails, put each part on its own line. So the basic intuition is natural and obvious.
---
But I always want to see how these algorithms are tested with real languages, and how they perform. I'm still not sure how easy it is to encode all the language specific rules in these "cost functions", but I may give it a stab (I have more than one formatter to write!).
The paper says it's tested on Racket S-expressions, and that there is a large amount of non-trivial convention around that syntax. But I think that's still a far cry from C++ or Python, in both the amount of syntax and how many users / how much code, etc.
I do wonder about the problem of computing layouts from scratch vs. fixing existing layouts. And the problem of formatter upgrades causing churn. My impression is that go fmt tends to fix things, erring on the side of leaving code alone, and people seem to like that? I guess the fear is with the "global optimization" algorithms, the formatter will make a bunch of choices and it's hard to figure out why.
I’m not sure what that would even mean. It definitely intends but maybe there are some edge cases where it has no opinion - like a long function signature with too many parameters it leaves alone unless you manually start new lining things
Is this remarkable? I also find black, the Python formatter, to be very reliable. Would anyone really use these tools if they occasionally munged your code?
Black is actually the reason I've been drifting from indifferent to against linters/formatters. It once broke our code around string handling, and it sometimes makes some odd choices when splitting long function calls - in a way that's inconsistent and reduces readability. And because they refuse to make it more configurable, you can't fix these cases.
Meh, people seem to have an inflated view of Prettier. I find that it's at best ok, but has produced enough frustrating errors that I just turn it off.
At $PREVIOUS_WORKPLACE, it totally removed the burden of formatting issues in PRs.
It’s far from perfect but at least everyone in the team was producing the same style and we could focus on logic errors rather than formatting (which is the first thing you spot and can’t ignore when doing a code review).
Formatting errors are at best an incidental detail that nobody should be wasting time on regardless of where it pops up; if prettier helps, great, but in its absence, I don't believe a trivial formatting inconsistency should illicit more than a tiny note among other problems you'd ask to be fixed. If the formatting errors are so frequent and so glaring as to warrant a negative review on that basis alone, such that you feel a mediator is required, then I'd wager Prettier may be obscuring other communication deficiencies.
That said, I do believe in the value of consistent formatting tools, I just think Prettier is a somewhat lazy choice that attempts to skirt responsibility for deciding on things or cultivating agreement. It's a disfunctional team who's members care too much about their opinions on such trite topics, and/or who aren't capable of coming to agreement on a common set of them.
For PRs, I've always just asked someone to run their formatter if it's clear they forgot, and usually there's a common config used by some formatting tool, it's not worth much beyond a a one-liner to make these decisions, and you should be able to do this periodically as things change.
Formatting is extremely overrated. It's important, don't get me wrong, but developers today seem to have this fetish for having a bunch of formatting rules on top of a litany of linter rules, as if the number of problems solved scales linearly with the amount of guard rails added. A level of it is useful, but so much of it is a waste of time and can lead to idiotic situations where things conflict or override one another. Not to mention time wasted bikeshedding this stuff.
Prettier, to me, is about as average as these tools come. It's not particularly offensive, though I don't understand why it's not way faster than it is.
I've worked with a number of developers whose output without these tools is a giant, unreadable mess. Training juniors to be reliant on this stuff does more harm (to them) than good.
If I'm reading this correctly, you think juniors should live without formatters because they need to learn to format manually?
I entirely disagree. Juniors have to learn so many more important things - how to logically structure code, testing, working on teams, git...
Why take time away from learning those (and similar) concepts to teach them something a tool does well and, if necessary, they can learn later?
I like it to deciding to teach teens how to drive with a manual transmission instead of an automatic one- they need to be able to drive and not hit things, and the more we can simplify that, the happier we all are. If needed, some kids can go back and learn how to use a stick shift.
> If I'm reading this correctly, you think juniors should live without formatters because they need to learn to format manually?
You did not interpret what I said correctly. Not that you had much to work with, but that small wall of text is based on a major extrapolation.
I said completely relying on these tools is doing them disservice. How do you train your muscle memory when the tools are doing everything for you. I, for one, believe proper formatting is a sign of care and it's really easy to spot when someone is not paying attention.
Only an fool would waste time on manual code formatting. The editor should automatically apply the organization's formatting rules. No muscle memory is required.
https://github.com/prettier/prettier/issues/15942
My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)