Skip to content

A discussion on changing the default value for trailingComma in Prettier 3.0 and/or TypeScript #9369

@Zamiell

Description

@Zamiell

Related to: #68 (Enforce Trailing Commas by Default)

Apologies if I missed any other previous discussion; I tried to go through and read any past threads on the topic.

In the Prettier 2.0 release notes blog post, Georgii Dolzhykov explains how Prettier decided to change the default value for the trailingComma option from none to es5.

Georgii links this excellent blog post from Nik Graf as justification for this change. In short, trailing commas result in:

  • cleaner diffs
  • easier code-manipulations

Looking over the relevant issues (#6888, #6910, and #6963), this did not seem to be a controversial change. And indeed, I think it can be said that this was a sensible and a welcome change for Prettier.

While the es5 default is a step in the right direction, it still results in missing commas for e.g. the final argument in a function call (and perhaps other some places, not 100% sure). Obviously, programmers are going to want commas after function arguments for the exact same reasons that they would want commas after array elements - all of the points that Nik Graf raises in his blog would equally apply to both situations.

In a previous issue on the topic (I can't remember exactly which one), lydell smartly mentions that IE11 does not support trailing commas in function args, and that IE11 is the final release of a major browser. Since IE11 still has some adoption, lydell argues that it would be inappropriate for Prettier code to not work with IE11 out of the box. That seems sensible and I don't think that most people would argue with that.

However, IE11 usage will fade over time. lydell mentions in issue #68 that the default value will change from es5 to all "some day", which is fantastic news. One goal of starting this discussion is to try and narrow down "some day" to something more specific. 2 years? 4 years? Would changing the default in Prettier 3.0 be too early?


In the meantime, it strikes me that having to support IE11 is not something that should be applicable to TypeScript code, since any ".ts" file would obviously have to be transpiled by the TypeScript compiler before it would ever hit IE11.

At the risk of sounding heretical, I'll ask: what if Prettier had a trailingComma default value of es5 specifically for JavaScript files, and a default value of all for all other languages? (Or, similarly, a trailingComma default value of all for TypeScript, and es5 for all other languages, whichever is better.)

Cons:

  • Admittedly, doing this would compilate the tool; are there any other settings that function like this? I suspect not.
  • Similarly, it would make the documentation for the trailingComma section a bit wonky.
  • Doing this goes against the spirit of the tool to be as simple as possible.

Pros:

  • On the other hand, having trailing commas after function arguments would clearly provide value to the TypeScript users of Prettier, for all of the reasons described in Nik Graf's blog.
  • Many users of Prettier are now getting comfortable with trailing commas (since the introduction of it in Prettier 2.0). However, it is a bit weird/annoying that some places have trailing commas and other places do not.
  • Georgii Dolzhykov, Simon Lydell, and the other members of the Prettier team seem to already acknowledge and agree with the benefits of trailing commas.
  • Another thing to note is that such a feature would only be a short-term aberration. In the long-term, when Prettier stops caring about IE11, the global default would change to all and all remnants of the split would be cleaned up and forgotten.

I acknowledge that any change in a default value would probably only belong in a major version bump (correct me if I am wrong). So consider this a proposal for Prettier 3.0 if the global default will not change to all at that time.

In closing, thanks for the excellent formatter.

Metadata

Metadata

Assignees

No one assigned

    Labels

    lang:typescriptIssues affecting TypeScript-specific constructs (not general JS issues)status:needs discussionIssues needing discussion and a decision to be made before action can be taken

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions