Prettier 2.0 – 2.0 2020

[lydell]

We already have a Prettier 2.0 issue – #3503 – but tell you what: Time’s up for that one. As of this writing, Node.js 8 is scheduled to expire early on December 31, 2019. And we still support Node.js 4. In two months we will be 6 versions behind!

Supporting Node.js 4 and Node.js 6 has been a real hassle lately as our dependencies (rightfully!) has stopped supporting them. We have spent a lot of unnecessary time getting tests to pass in Node.js 4.

So here’s my suggestion for a 2.0 of a Prettier 2.0 issue:

The main focus should be dropping support for unsupported Node.js versions. Let’s aim for releasing Prettier 2.0 early in January 2020 with support for only Node.js 10+.

Apart from that we could do some easy breaking changes:

• Change the default for trailingComma to es5, as discussed in the original Prettier 2.0 thread.
• Remove deprecated stuff.

When that is done – if we have time, we could do more things. We’ll see. For example, it would be really nice addressing #5588 (making all unsafe template literal formatting opt-in). I also have a suggestion for lots of improvements for Prettier’s CLI and API, but I’ll open a separate issue for that.

/cc @prettier/core @brodybits @fisker

[azz]

Sounds good to me! Let's get this shipped.

[fisker]

@lydell you fogot Change the default for singleQuote to true

[lydell]

@fisker No, I left that out on purpose. I don’t think we should do that. As far as I can tell, there’s been no consensus on that change. Let’s not discuss singleQuote for this release so that we can stay focused on the important parts.

[brodybits]

I hope we can drop use of a bundled typescript dependency in favor of babel-ts as proposed in PR #6400. I think this would be much less bulky, also reduced variety of bundled dependency licenses (I think TypeScript is Apache 2.0.).

[lydell]

That would be nice. Maybe we can change to babel-ts as the default TypeScript parser in 2.0 and remove the typescript parser in 3.0 if it all works out.

[thorn0]

On the other hand, we might want to go the other way round and use TypeScript to parse JS. If Prettier is going to format JSDoc, TypeScript already parses it for us.

[manuelbieh]

Is this ticket the right place to propose changes of default values? If so, I would like to put arrowParens up for discussion. This should imo be changed to always to provide maximum consistency. See my tweet from a few weeks ago for why I think avoid is a mistake:
https://twitter.com/ManuelBieh/status/1181880524954050560

[Shinigami92]

IMO, it is not the right place 😕
We should discuss any suggestion to change a default value in a separate issue
Then we could refer to the issue in this issue

Otherwise it could be very messy in this issue

[thorn0]

@manuelbieh It's out of scope for this release.

[alexander-akait]

@thorn0 I think we should consider arrowParens: always. I have worked with many projects, both large and small, and most of them use always for the arrowParens option. Also it will not change many lines in code

/cc @prettier/core what do you think?

[thorn0]

This release is supposed to be focused only on the things a consensus has been already reached about.

[alexander-akait]

@thorn0 we have time to discussion about other things is not it so? I see no reason to delay things that can be solved quickly and without pain

[Shinigami92]

@thorn0 we have time to discussion about other things is not it so? I see no reason to delay things that can be solved quickly and without pain

You are free to open several issues for your proposals

[lydell]

After three years of going through Prettier github notifications almost daily, I’ve decided to take a break. I’ll be around if you ping me, and I’m subscribed to a ton of issues and PRs, but I won’t be looking at new stuff for the forseable future.

@thorn0 @sosukesuzuki @evilebottnawi and more, are you up for finishing up on 2.0?

[VincentLanglet]

Is there any timeline for the next (2.0 ? 3.0 ?) major version ? :)

[thorn0]

@lydell

are you up for finishing up on 2.0?

I'd give it a try if we stick to the original plan (because time's up):

The main focus should be dropping support for unsupported Node.js versions. Let’s aim for releasing Prettier 2.0 early in January 2020 with support for only Node.js 10+.

Apart from that we could do some easy breaking changes:

• Change the default for trailingComma to es5, as discussed in the original Prettier 2.0 thread.
• Remove deprecated stuff.

What do I need to proceed?

[kachkaev]

Apart from that we could do some easy breaking changes

• Change the default for trailingComma to es5, as discussed in the original Prettier 2.0 thread.

🚀 #6963 (merged already)

Voting results for other breaking changes in config defaults:

✅ #6929: Change arrowParens to always by default for 2.0 (PR #7430)
✅ #6932: Change endOfLine to lf by default for 2.0 (PR #7435)
❌ #6931: Change quoteProps to consistent by default for 2.0

Did I forget anything?

[lydell]

@thorn0 There’s the release checklist and the release readme. The release script is really nice and a bit interactive, telling you what to do. I’ve only done one or two release before so I’m not super familiar with this, though. Most time is needed for the changelog/blog post. You should now have npm publish access.

[fyeeme]

Can #/5377 bracketSameLine (support for vue)be considered?

as vuejs/eslint-plugin-vue has the rule "html-closing-bracket-newline" , but prettier could not fix it.

it's really to be need, many thanks.

For React/JSX - Prettier has an option to allow tags to close on the same line as the declaration, rather then on a new line:
jsxBracketSameLine: true:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}>
  Click Here
</button>
jsxBracketSameLine: false:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}
>
  Click Here
</button>

[karlhorky]

If 2.0 is still open, just like @kachkaev's list above, here's also another issue where the votes clearly show a favor towards changing the default:

✅ #4102: Change the default value for singleQuote to true (PR #7466)

[janaagaard75]

It's really hard to use the number of votes in #4102 without having something to compare them to.
It could just be people searching for "how to set up Prettier to using single quotes", ending up on that thread, and then obviously giving it a thumbs up. We would need an alternate timeline where Prettier was defaulting to single quotes, and an issue about switching to double quotes.

[0az]

What about #3806 (implemented in #7111)?

Unlike singleQuote, it's uncontroversial and has consensus. I don't recall any significant opposition, or any opposition at all to that change. Reading through the comments, this comment suggesting a variant and this comment in opposition are the only ones with significant amounts of downvotes.

[miyaokamarina]

What about #3986? For the last few years I’ve avoided using intersections in any way, even in places where I can’t do without them, because Prettier is turning them into complete nonsense.

[0az]

#3988, the PR for #3986, was closed as "inconclusive". I do think that it should get revisited, if only for consistency with the proposed binary operator change.

And given that the latter's consensus is more or less settled, in my opinion it's safe to conclude that the intersection change will see similar support, or at least lack of significant opposition.

I'm willing to try my hand at a PR for the lot this weekend, if I end up having spare time. Does anyone know of any similar issues with consensus?

[karlhorky]

Congratulations on the 2.0 release! 🎉