Live data from Hacker News

Prettier 2.0 – Opinionated JavaScript formatter

prettier.io

41–50 of 91 posts

Re: Prettier 2.0 – Opinionated JavaScript formatter

#41

Earlier quoted context omitted.

Why not just change it to a high value? Or prettier-ignore exceptional lines?

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, lik…

You can controll the formatting with empty comments

eg, if you dont like

    const {a, b, c} = props;
you can do

    const {
      // 
      a, 
      b, 
      c
    } = props;

Re: Prettier 2.0 – Opinionated JavaScript formatter

#42

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 wh…

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#43
post #42

Earlier quoted context omitted.

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#44

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 wh…

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#45

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 wh…

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#46
post #7
post #4

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.

^^^ what the op said. You'll regularly seen diffs in minor versions, and even patch versions.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#47
post #24

In order to get this working with vim's prettier highlighting, I had to add this to `.prettierrc`: { "trailingComma": "es5", "arrowParens": "always" } Prettier 2.0 changed this to be the defaults, but for some reason the editor plugin wasn't acknowledging it. Also I added a script command to format all the code in package.json: { "scripts": { "prettier": "prettier src webpack data --write" } } Then `npm run prettier`…

> but for some reason the editor plugin wasn't acknowledging it Is it using a bundled pre-2.0 version of Prettier?

Not sure, but it's this package: https://github.com/prettier/vim-prettier

Re: Prettier 2.0 – Opinionated JavaScript formatter

#48
post #42

Earlier quoted context omitted.

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.

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#49
post #42

Earlier quoted context omitted.

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.

Configure your git blame to ignore cleanup changes.

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#50

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 wh…

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

Post reply on HN