Prettier 2.0 – Opinionated JavaScript formatter
prettier.io
prettier.io
I feel like the cost of changing defaults is wildly underestimated because it's decided on by people who are so deeply engaged in the product.
It means either all my code now needs a config file added or all my code will need to be updated.
We can't expect everything to be perfect on day one, nor should we be stuck with the poor choices we made when starting a project. Maintainers should be allowed to change their mind after careful consideration and community consensus.
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...
Personally tho I haven't had an issue navigating back another revision. UIs are good at handling that kind of interaction, and I rarely use blame without a UI. (nearly every other git interaction: CLI all the time. but not blame.)
Especially when working with syntax heavy compiled languages like Rust, autoformat on save frees me up enough mental capacity for me that the costs are well worth it for the extra development speed. I just use Git Lens and some custom git aliases to get around the messy logs, whereas my last team handled the payment frontend for a large company so tracing the history of changes was taken way more seriously and reformatting someone else's code outside of organized refactorings, let alone autoformat, was disqualified from the start.
{
"trailingComma": "none",
"arrowParens": "avoid"
}
I just updated the PhotoStructure codebase, and even with that revert of those 2 defaults, almost 100 files and several thousand lines of diff resulted: https://twitter.com/mrm/status/1241792817338257409
Seems like a pretty good reason to change that one at least, since it seems to imply they've wanted trailing commas but didn't do it for compatibility reasons.
Just `JSON.stringify` whatever object it is instead.
I think there's another way to look at it. It's more "we have decided on X so YOU can move on to more important issues."
With Prettier, you just follow their opinions. Their opinions can change, and your code might look different, but it doesn't really matter. It might reformat a few lines, but the point is that it's still consistent across your team (without anyone having to memorize a bunch of rules).
I think you are overstating how hard it is to add the config (pro tip: you can add it to package.json) and how painless it is to run the formatted for the whole project.
The changes to the defaults are small and (in my opinion, worth it).
This is great! When I'm scripting in Node.js I tend to prefer either of these two styles, with the second one being normally a cleaned-up version of the first one:
const res = base
.map(a => a.b)
.filter(b => /abc/.test(b))
.join('\n');
const res = base.map(extractB).filter(isAbc).join('\n');
However at the same time I'm not thrilled about prettier breaking changes. It is supposed to be the one way of doing things, so now a project might have different people with different prettier versions, making it a ping-pong game if someone has prettier 1 and someone else prettier 2.
This is a wiser design because the formatter can't know what the best layout is, and a formatter really ought to only format something where there's is an unequivocally, universally correct way of formatting something.
As an example, sometimes table-driven test are better written compactly, sometimes better verbosely. As a naive example:
for _, c := range []testcase{
{input: 1, expect: 10},
{input: 2, expect: 20},
{input: 3, expect: 30},
} {
assert.Equal(t, c.expect, someFuncToBeTested(c.input))
}
{
input: 1,
expect: 10,
},
This is something Prettier doesn't always do correctly, and with Prettier, you don't have a choice. Opinionated is good when there is just one answer, but not when there's a range of possibly answers.
But I also have wished on multiple occasions that prettier was just an opinionated preset on top of a much more configurable core, which would make it less of a taboo to add options for what are obviously massively divisive formatting preferences.
Case in point, all the most popular issues in the repo are some form of people asking for options or changes to the current behavior: https://github.com/prettier/prettier/issues?q=is%3Aissue+is%...
And let's face it, that whole idea of a 1-size-fits all JS code formatting tool to end all formatting debates? That ship has sailed a long time ago. The debate just moved to what prettier options to use: https://prettier.io/docs/en/options.html
I think the real value of prettier these days is that we can debate as a team once, decide on an option, and then have that decision be enforced automatically moving forward. A configurable core + opinionated defaults can serve that use case just as well.
//prettier-ignore
For work, sure agree.
Also, you may be underestimating beginners. If someone can learn git, how to make a substantial code contribution, and lift it into a PR, they can run your `npm run prettier` step. :)
That’s different from a more structured template-style language like JSX, where there are only a few valid places to embed JS expressions so it isn’t too challenging to make them all look good.
See Prettier example in ESLint section of "How I Learned to Stop Worrying and Love the Types & Tests", https://p.migdal.pl/2020/03/02/types-tests-typescript.html#e....
We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.
At first I disliked things about Prettier. For example, indents violate eslint’s “indent” rule with multiline ternary alignment. However, I just turned off those eslint rules and stopped worrying about it b/c Prettier’s format is “good enough” and saves me a ton of keystrokes.
That's mostly why I don't like prettier, sometimes you want a bit of control over code formatting when several options are possible, prettier don't allow it. I use vscode formatter (actually it's TypeScript compiler formatter) instead
Other things I dislike with prettier, like how it'd force parenthesis in a `2 + 3 * 4` expression, where it's a bit superfluous. Or string templates line returns on expressions https://github.com/prettier/prettier/issues/3280
Where it does do something awkward e.g. to long expressions with lots of operators in, usually it’s actually a sign that you can make it clearer by splitting it into multiple smaller expressions which helps overall readability.
I think you can also tell prettier to ignore certain lines, though I don’t think I’ve ever needed to.
eg, if you dont like
const {a, b, c} = props;
const {
//
a,
b,
c
} = props; {
"trailingComma": "es5",
"arrowParens": "always"
}
Also I added a script command to format all the code in package.json:
{
"scripts": {
"prettier": "prettier src webpack data --write"
}
}
It even formatted my JSON and SCSS files. Didn't recognize prettier could do that.
Is it using a bundled pre-2.0 version of Prettier?
Only couple of issues it has is no 'ignore formatting for this piece of code' feature and it occasionally formats comments oddly (i.e. enough to make them unreadable) in certain edge cases like in ternary expressions, so you have to manually edit comments from time to time, but this hardly ever comes up.
Check out Preferences -> Tools -> File Watchers.
No idea how good it is though. Please tell us. :)
prettier for js, ts
Speaking for myself, I advocate "one formatting to rule them all" in terms of just taking defaults, and one of my arguments is that, if there's something universally wrong about a prettier default, then it should be changed universally. And if it isn't universally wrong, just go with the default.
Some things are obviously bugs, especially the chained line break problem.
Bur the semicolons config they added back in the days just baffled me.
Personally, I would rather a project use a formatting tool that outputs a format I don't like than not using a formatting tool at all.
I just don't want to have to waste mental bandwidth on formatting ever again.
I had the impression Prettier follwed the spirit of Go fmt, which had that claim.
const identity = function (value) {
return value;
};
This comment was a hidden gem in this thread, I've bookmarked that blog post.
Are you avoiding NPM as well?
Seems like a curious requirement for JS development
For what it is worth, the replacement for NodeJS (Deno) is removing the use of npm, so I am not alone in my dislike of the centralised registry idea it seems.
Deno's approach on the other hand is doesn't force any of that indirection onto the user, and is analogous to (and compatible with) the model of modules on the web. Package management systems can be easily layered on top of that if the use case actually warrants that extra indirection, rather than having it baked into the core of the runtime.
Aside: I wouldn't sell what I do as JavaScript development, though.
So it would be difficult to purge your system from anything that can run JS :P