A bit irritating that formatting zealots are changing the defaults. What can possibly drive the decision to change whatever option it is they landed on and deployed? It's contrary to everything they claimed Prettier was about: for better or worse, we have decided on X so we can all move on to more important issues.
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.
Is the cost really that high? For the vast majority of projects, all developers will need to do is run "yarn prettier".
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.
If you can use GitHub but not Git, I'm not sure you can really say that you know version control. Fine for designers who are just helping out in projects and don't really know to but developers who manages merges, backports and alike should really know the insides of Git, not just the GitHub GUI.
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.)
The loss is a bit of convenient tooling but it can be replaced with some slightly less convenient tooling. It's not going to be an architectural limitation and you can treat it as a relatively simple per company/team/project tradeoff.
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.
This used to have no value to me. But years into my career I discovered that I can't live without it. Detective work on the history of code is vital to truly groking why things are the way they are in code bases.
It will likely conflict most in-progress PR. For PRs that are large and long lived it will be a PITA to maintain and will further slow integration so, likely, yes.
I ran formatters on a largish codebase over Christmas when all the PRs were done. You just have to pick your moment. If it's really hard then get everyone to agree on a date to do it and make it each developer's responsibility to either merge before or rebase after the change. It can be done.
Know that you'll still have non-trivial diffs when switching from 1.x to 2.0 due to other changes (like "the `function` keyword should always have a space after it because consistency").
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
>Before version 2.0, Prettier was avoiding trailing commas by default where possible. This made the resulting JavaScript compatible with now very old environments such as IE8, but implied some missed opportunities.
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.
I find trailing commas annoying because every once in a while I need to copy some object to use as JSON and... it doesn't work since JSON doesn't support trailing commas.
To be fair, that's more of a JSON problem than a JS one. FWIW, JSON is also missing quote-less keys, object literal shorthand, non-decimal numbers, values that are non-simple literals, and probably a bunch else from JS object syntax.
Just `JSON.stringify` whatever object it is instead.
Why the down vote? Prettier calls itself "an opinionated JavaScript formatter". It _had_ an opinion that I agreed with, and now it doesn't. I just offered a perspective on why I don't agree.
That’s not going to work with object keys anyway, which need to be quoted in JSON. You can’t even configure Prettier to do that unless your keys are invalid JS identifiers.
I'm not sure how you can say these are zealots making these changes? The three defaults things they changed all seemed incredibly sane, and were made for really good reasons.
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).
We had to change the old default because of TypeScript complaining if the param has a type annotation and no parens. So it's more consistent with TypeScript now as well. I had to argue for this exception to be added to our config, so it's a nice bit of validation that Prettier has come around.
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');
The second one would be split into different lines with Prettier 1.x, which was annoying since I would explicitly extract those methods into separated functions for clarity. So this is amazing for my personal projects.
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.
I prefer Gofmt's strategy/philosophy, which is to mostly let the developer control breaking, and only format around it. Gofmt will format everthing strictly, but will leave decisions about "layout" to you.
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))
}
If the formatter starts splitting each testcase entry up over several lines, like so:
{
input: 1,
expect: 10,
},
...then you potentially lose readability. In other cases, you have more complicated structs that might fit on one line, but deserve to be formatted across multiple lines.
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.
I personally really enjoy the automatic line breaking behavior of prettier as it frees me from having to make this entire class of purely stylistic decisions but still have code formatted in a reasonably legible manner.
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.
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.
I prefer not to add an extra step for newbies devs contributing to my open source projects. So if someone makes a PR and it's not well formatted, not a big deal.
They don't need to apply prettier, but it does no harm that it's sitting in their node_modules pegged to the version you're using.
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. :)
I have a pre-commit hook configured to format staged changes. It uses husky and pretty-quick. With this approach, you should get standard commits, even if the user’s installed tooling differs.
This is actually quite challenging because the template language allows you to insert template tags into any location in the template file, and while people usually put them in reasonable places, there’s no guarantee. For example, someone could do a thing like `{{ less_than }}div class="foo">abc</div>` and that would be totally valid but a nightmare to parse.
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.
Prettier was originally created by James Long, who also created Nunchucks (which is the Node port of Jinja2, since we were all familiar with Jinja2 at Mozilla). I don't really have a point since he's not involved in either anymore; just thought it was interesting!
Did they change an option to disable lineWidth? In 1.* it was not possible, which was my single biggest issue with Prettier.
Many times it made code less coherent, due to forcing a few lines to be collapsed into one.
This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit.
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.
I’ve learned that the benefit of Prettier outweighs its cost in this regard.
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.
if you put a high lineWidth value, you'll have your object literals or destructuring mostly one-lined, etc.. often not desirable (for 4+ props)
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
I felt the same at first but I’ve honestly found after about a year of using prettier on every project that you just get used to the way it formats stuff and it’s a non-issue 99% of the time.
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.
I have been looking for, but haven't found, a similar package for Java projects. Ideally my team can add it as a save-hook for everyone using IDEA, then we can have a pre-commit hook that checks to ensure compliance. Would be eternally grateful for anyone that can point me in the right direction!
I'm very happy using this, coming from prettier with JS/VSCode and looking for a similar dev experience in Java/Intellij - it has an IntelliJ plugin that works well. Last time I looked I couldn't find any good IntelliJ plugins for the Java implementation of prettier which was a dealbreaker - I need the format on save. Anyway, this is a great tool, just works.
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.
There’s https://github.com/jhipster/prettier-java, which expands Prettier to work with Java, but I’m not sure how complete or thoroughly-tested it is. It also requires that you have Node installed, which could be be a downside for people who only work with Java.
finally you can run `npx prettier --write .` and get a folder formatted without any installation or configuration. This is a great decision. Congratulations on the release team!
That's probably useful in some cases but I'd still recommend pinning the version, since different versions of prettier format code differently and different team members will end up with conflicting changes.
IMHO, when writing long logical expressions, putting the logical operators to the beginning of each following line (instead of to the end) makes them much easier to read.
I'm not sure how dedicated prettier is to "one formatting to rule them all" since it's configurable per-project. Switching between different projects with different prettier configuration is very low friction.
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.
I don't think Prettier ever claimed to be the one true formatting everyone must use for it to be successful. It's a tool that formats code nicer then most other tools.
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.
Not sure how much open source you've done, but StandardJS is used in a lot of open source JS libraries/projects, and they have the "Add a space after keywords" and "Add a space before a function declaration's parentheses" rules in it, so plenty of open source projects does it like this.
I avoid NPM if I can for JS development (after all not all JS/TS development requires NodeJS) so it is painful to see people use npm as the installation method for their projects or tools when I am trying to write something simple.
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.
IMHO, Deno's approach to package management, that is to say, no package management ("packages" are just source files that you'd import directly using urls or file paths), is a breath of fresh air compared to the status quo in node where to import some javascript that's already hosted at some url (say on github), you first have to "package" it by describing it with some manifest, uploading it to some registry at a different url than the original, and then "install" it using a package manager from that other url, and at the end of the day not even have any guarantee that the content of that thing you installed actually matches what you saw at the original url.
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.
For the last 25 years, many apps have come with their own JS engine for scripting abilities. Ms Office, Photoshop, et. al. Not just the web browser. And more and more "native" apps have a built in JS engine. And then there's apps that not only have a JS engine, but a whole browser (Electron, Nw.js).
So it would be difficult to purge your system from anything that can run JS :P
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.