Hacker News Reader

Comment by Waterluvian | Hacker News Reader

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.

View on HN

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.

Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.

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.

--ignore-rev: 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.)

Configure your git blame to ignore cleanup changes.

https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

This changes everything. Thank you!!!

If GitHub doesn't automatically support the feature (article says it doesn't) I don't think it'll be very useful for many teams.

git 2.23 isn’t that old - seems like something that GitHub could support in the future

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.

Thanks for sharing this. This issue is holding so many code bases behind.

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.

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.

Some team in my old job use to have a term for this - "grabbing the virtual chicken". It was essentially a giant distributed lock :)

Here's a .prettierrc config file to revert the new 2.0.0 config changes:

    {
      "trailingComma": "none",
      "arrowParens": "avoid"
    }

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.

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.

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.

No comments either, which is one major reason I strongly oppose JSON as a config-file language :|

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.

Fortunately, if you use Prettier to format your JSON files too, it’ll quote unquoted properties and remove trailing commas: https://prettier.io/playground/#N4Igxg9gdgLgprEAuEwA6UAEmDOE...

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

I wouldn't call change of `arrowParens` to `always` as "incredibly sane". This is just a differt opinion about what is "better". I have different.

I like it, because it's consistent. If you remove or add a parameter to a function, you have parenthesis either way and don't have to think about it.

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.

You can just not upgrade.

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

You have the option of not using these sort of tools and styling the code yourself.

Reply on news.ycombinator.com