Prettier 2.0 (old)

[azz]

Note added by @j-f1:

This is NOT the current plan for Prettier v2.0. We’ve significantly scaled back our plans for what Prettier 2.0 will do, allowing us to get a less-controversial release out sooner: #6888

---

I've been thinking a bit about what we would do if (don't create a milestone just yet 😉) we were to do a Prettier 2.0 release with some API/CLI breaking changes. No significant changes to code formatting other than perhaps changing some defaults.

Easy?

• Enforce Trailing Commas by Default #68/Can we enable the dangling comma on this project? #3469 - Change default value for trailingComma to "es5".
  The diff advantages alone are excellent, and this seems to be commonplace among the most popular JS projects.

CLI:

• config file doesn't work at the way other libraries do #2691 - CLI defaults to "**/*.{js,ts,...}".
  People should just be able to do prettier --write without passing messy globs #0CJS

• Consider replacing the "parser" option with "language" #2846 - Replace the "parser" option with "language".
  e.g. echo ".foo {}" | prettier --language css
  Keep --parser flow or perhaps support something like --parser.js flow for future extensibility.

• Remove --flow-parser option.
  Has been deprecated for a long time.

For debate

• Consistently add quotes to object keys #838 - Consistently add quotes to object keys.
  e.g. put quotes around origin in this example:

  const headers = {
    'origin': 'foo.com',
    'access-control-allow-origin': '*',
  };

• Change the default value for singleQuote to true

  • Airbnb, standard, xo, and probably the majority of JS devs prefer this. Maybe do a Twitter poll to gauge opinions on this.

To be clear, the Airbnb config requires single quotes for JS and double quotes for JSX.

Outdated

• Consider removing default parser / Skip processing unsupported file types #2884 - Remove the default parser. Fixed by Don't default parser to babylon #4528

• Space after function keyword - MOVED to #3847! #1139 - Put a space after the n in function () {}

[vjeux]

All the changes you mentioned sound good (even switching single quote), now the big question is: do we think that the current suboptimal behavior is worth a breaking change. I’m not sure (in either way).

For consistent key quotes, I think we should just do it regardless, I’m not sure why we haven’t already.

[azz]

I'm not certain either. The CLI breaking changes listed are quite small, and probably wont affect a large percentage of projects. The changes to the options are are trivial because you can just change them in a config file, so the "migration path" (if you can even call it that) is quite simple.

But there's always the risk with breaking changes that people will not know that and simply stick with the older version.

[ikatyang]

• drop Node v4 (Maintenance LTS End: April 2018)
• remove all deprecated options
• remove exitCode: 2 from CLI, or figure out when should we apply exitCode: 2 as it's very unclear now.

[bakkot]

One thing I'd personally find really nice: removing the dependencies on non-JavaScript parsers. (In particular, all parsers other than babylon.)

For example, a lot of people aren't using prettier to format TypeScript. But if they install prettier, it pulls in that whole package, which is something like 30 megs by itself.

That makes me sad. If prettier adds support for python and installing prettier starts downloading python binaries, that would make me really sad.

I would be delighted if prettier could stop trying to ship all of the parsers for anything anyone might want to format. Presumably then trying to format (say) a .ts file would give you "Error: to use prettier to format typescript, you'll need to add the 'prettier-ts' package; run `npm i --save-dev prettier-ts`".

[azz]

@bakkot Current package is 1.54 MB with zero dependencies on npm.

npm-module-stats

$ npm-module-stats --name=prettier --version=1.9.2 --format=minimal 
 Requesting module prettier@1.9.2
Results:
Total Size  1.54 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.5.3 --format=minimal 
 Requesting module prettier@1.5.3
Results:
Total Size  1.11 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.4.x --format=minimal 
 Requesting module prettier@1.4.4
Results:
Total Size  1.03 MB
Total Dependencies  0

$ npm-module-stats --name=prettier --version=1.3.x --format=minimal 
 Requesting module prettier@1.3.119.0.09.0.05
Results:
Total Size  943 kB
Total Dependencies  33

[bakkot]

@azz Ah, I missed that the package.json in the repo isn't the one which gets published, sorry.

(npm-module-stats apparently gives compressed compressed size, not on-disk; on my machine a fresh install ends up at 6.3 megs, most of which is the various non-JS parsers. Still, probably not worth worrying about.)

[azz]

It's the size of the tarball that's on npm:

$ du -h $(npm pack prettier@latest)
1.5M	prettier-1.9.2.tgz

[lydell]

I’d like to make a poll to see if the bracket-spacing option could be removed: #715 (comment). It’s harder to say no to new spacing options when this one exists.

[azz]

Facebook uses no-bracket-spacing, and it's actually kind of growing on me.

[duailibe]

Facebook uses no-bracket-spacing, and it's actually kind of growing on me.

If we were to remove the option, I'd vote to make "no spacing" the default, to be consistent with other brackets

[j-f1]

@duailibe I like the style with spacing since it’s easier to focus on the stuff inside the brackets if there’s whitespace around it IMHO.

[azz]

We probably can't change the value and remove the option at the same time - we don't want people to not upgrade because it changes too much of their code.

[duailibe]

@j-f1 That's pretty much what people who asks for spacing between [] and () say

[lipis]

Let's kill it.. 🔥

[alexander-akait]

@ljharb thanks for feedback, update first issue about this

[rattrayalex]

Can we conduct telemetry or ask users to share their configs somehow? If there are settings that a supermajority of users are choosing, we should probably set those as the default (and a github issue thread is not the best way to collect this data).

A google form listed prominently in the readme and tweeted & pinned might be enough?

[MasterJames]

I got use to having extra spaces after parenthesis like
function( valu )
I thought you'd be able to add your own regex search and match kind of expressions.
(.*\()(.*)(.*\))
and to replace
$1 $2 $3
with groups for making replacements.
If this is already possible please direct me to a documentation example for customization of formatting.
If this is not possible please consider this as a suggestions for a future release.

[j-f1]

I don’t think that would be a good idea since you could unintentionally break complex syntax; however, if you really want to, you could run a regex replace over your code after running Prettier.

[MasterJames]

I gotten use to most of these except extra space before a closing function bracket.
https://github.com/mrdoob/three.js/wiki/Mr.doob's-Code-Style%E2%84%A2

If there is a way to add space to function parenthesis I would feel at home with my code formatting.

[0az]

I proposed implementing #3806 in a major version bump, so it probably should get added to the list here.

[brodybits]

Sorry for the pressure but I really hope a major release will come soon with the following:

• completely drop support for old Node.js versions
• consider "breaking" dependency updates, rather than relying on old dependency versions to avoid breaking changes
• consider any other breaking changes that could be done with very limited controversy

Relying on old dependency versions makes the update increasingly more difficult over time. Supporting old Node.js versions makes this even worse. This seems to be a major diversion of time and attention that could be used for improvements and fixes.

My understanding from #6748 (comment) is that the new release should be coming in January 2020, with support for Node.js pre-10 removed.

Can someone from @prettier/core confirm?

Is there anything special that outside contributors such as @fisker and I should do to propose breaking or potentially breaking changes for 2.0?

P.S. Should this be discussed in a new issue? Should I raise a new issue to discuss this?

/cc @lydell @fisker @prettier/core

[lydell]

@prettier/core

[brodybits]

Can we pin this issue as well?

I think it could really help discussions with other projects, such as tildeio/simple-html-tokenizer#74.

[Shinigami92]

I crawled GitHub a bit and found out:

master:.prettierrc	count
not json	57
singleQuote: false	13
singleQuote: true	257

master:.prettierrc.json	count
not json	7
singleQuote: false	2
singleQuote: true	30

---

Total repos: 2648
3 Queries made and merged: "stars:>=10", "language:JavaScript", "language:TypeScript"
(1000 repos per query)

primaryLanguage	count
TypeScript	1000
JavaScript	1000
null	113
Python	89
Java	68
Go	58
C++	44
CSS	25
HTML	25
Swift	24
C	24
Shell	22
Ruby	19
PHP	19
Objective-C	15
Jupyter Notebook	14
C#	10
Vim script	10
Kotlin	10
Rust	9
Vue	9
Scala	4
CoffeeScript	4
Lua	4
TeX	3
Dart	3
Haskell	3
Objective-C++	3
Assembly	2
Elixir	2
Clojure	2
Perl	1
OCaml	1
Standard ML	1
Crystal	1
Batchfile	1
Rascal	1
V	1
Dockerfile	1
Julia	1
Makefile	1
Emacs Lisp	1

---

If you want, I could publish a repo for the crawler tomorrow ^^

[ExE-Boss]

@Shinigami92 What about singleQuote: undefined?

That resolves to singleQuote: false.

[nickmccurdy]

It seems like this also doesn't account for projects using the default Prettier config with singleQuote: false. It would help to check projects with prettier in package.json, but still excludes users that only use Prettier via their editor globally.

[jabacchetta]

It should be noted that any review of current prettier configs obviously excludes those who have chosen not to use Prettier (due to missing settings), even if they'd like to.

As I mentioned in my previous comment (with relevant links), because of the conflict between Prettier and Airbnb's style guide on parentheses-wrapped multiline expressions, anyone who follows the Airbnb style guide (both the code-quality and formatting rules) is not using Prettier (Prettier doesn't have the setting and ESLint has no plans to add auto fix for the conflict).

That's a massive developer base who would no doubt like to use Prettier but literally can't, as it currently stands. Keep in mind, these developers are using single quotes.

In other words, if the goal here is to figure out what current (biased) Prettier users are doing, then you'll likely see something pretty close to the current defaults. But surveying the developer community as a whole will yield very different results.

[Shinigami92]

Mh yea... it was late yesterday and I wanted to have some fun with GitHub's GraphQL ^^

I don't know if it's the right way to only look into repos
Like @nickmccurdy and @jabacchetta and others pointed out
it is not very representative and maybe there are repos that were to lazy to configure prettier and so on

[bakkot]

@thorn0 time to close this issue, I think?