I have never seen a formatter talked about this much, it is just a formatter and code is not poem, Jesus.
But there's an art to writing great code, no?
Why is Prettier rock solid?
121–130 of 163 posts
Re: Why is Prettier rock solid?
#122The 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
ESLint deprecated its formatting rules and recommends Prettier and dprint - https://eslint.org/blog/2023/10/deprecating-formatting-rules...
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.
Re: Why is Prettier rock solid?
#123[flagged]
Re: Why is Prettier rock solid?
#124> 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.
Re: Why is Prettier rock solid?
#125Earlier quoted context omitted.
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.
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 (pretti…
You can mellow the squiggles for stylistic errors in VS Code.
Take a look at the “eslint.rules.customizations” key in this file:
https://github.com/antfu/eslint-config/blob/main/.vscode/set...
Re: Why is Prettier rock solid?
#126Meh, 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.
Prettier real usefulness is in team projects. 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.
Re: Why is Prettier rock solid?
#127Earlier quoted context omitted.
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.
Conversely, my strategy is "press shift+tab to close the block and not have to screw around with matching {} everywhere".
Perhaps is because jetbrains make better structural editing than vscode, but I practically never have to type closing brackets.
Copying, moving, reordering, newlines, pretty much anything will keep correct pairing of brackets.
Re: Why is Prettier rock solid?
#128Earlier quoted context omitted.
Conversely, my strategy is "press shift+tab to close the block and not have to screw around with matching {} everywhere".
Perhaps is because jetbrains make better structural editing than vscode, but I practically never have to type closing brackets. Copying, moving, reordering, newlines, pretty much anything will keep correct pairing of brackets.
Sure, and I never have to type any opening indentation either, only closing.
Regardless, to me, this is such a minor issue that I don't consider it at all when choosing a language.
Re: Why is Prettier rock solid?
#129Earlier quoted context omitted.
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.
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 (pretti…
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.
Re: Why is Prettier rock solid?
#130Earlier quoted context omitted.
> until a particularly silly pedantic argument won them over. Which comment are you referring to? The release notes sound practical
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.
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.