You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#16152. @samal84 mentioned something like this but I couldn't parse what they meant without a code sample (is this it?). I'll take I can, if this is approved, take a stab at removing this error too.
If we have more community interested, we'll reconsider it.
How can I and/or the community demonstrate interest?
I think "looks like an error" / "looks pretty gross" are pretty subjective and contrary to the widely-adopted Airbnb styles, which prefer trailing commas on multiline lists, etc—to be honest, I used to be opposed to it but since we've adopted the Airbnb styles, they've grown on me, especially in that they can make Git diffing much more readable.
Disallowing them in this particular case ends up having the effect that trailing commas can be used everywhere but one place in our code, and also ends up putting our linter config at odds with ts (or makes us disable the linter for this style, which means we can't be consistent elsewhere).
I entirely understand that there are complications that can arise from implementing this, including the "what if" listed, but I think it's worth reconsidering.
Reacted by Josh Ghoulberg 👻, Brian Crowley, Sámal Rasmussen, Brian Kim, Alan Pierce, phrohdoh, Willem Garnier, Ilia Baryshnikov, Paris Brentas, Cathrine Vaage and 1 more
My mental modal of trailing commas is that trailing commas are now allowed in all cases in JS, and I think that's a lot simpler than having to remember which syntax cases support them and which don't. Previously, the language had some opinions on when they should and should not be used, but now I believe they're consistently allowed in all comma-separated lists (arrays, objects, destructures, imports, exports, parameters, and arguments, though technically not after rest elements), and it's up to the community and the tools to decide if and when to use them. The benefit (described at https://github.com/tc39/proposal-trailing-function-commas ) is relatively minor, and it can be a source of inconsistency, but with tools like Prettier, you get the benefit for free without having to think about it, so I personally have a slight preference for trailing commas everywhere so that you get slightly cleaner diffs.
I usually assume that TypeScript is consistent with JavaScript in its design decisions (and it usually is), so I was surprised to learn that trailing commas were mysteriously disallowed in this one case. Obviously it's not going to be a huge roadblock for anyone, and multiline type argument lists are super-rare anyway, but I think consistent rules mean a little less cognitive overhead.
Put another way, I think the two most reasonable coding styles are "never use trailing commas ever" and "always use trailing commas for multiline lists". That second one is now possible in JS as of ES2017, but it's still not possible in TS due to this one disallowed case.
Reacted by Brian Kim, Sámal Rasmussen, Ben Saufley, Josh Ghoulberg 👻, Alec Larson, Nicky McCurdy and roshal
Perhaps this title should be updated to "Allow trailing commas in type arguments" since this seems to be the canonical issue for this? This seems to apply to all type arguments (but not type parameters).
Reacted by Josh Ghoulberg 👻, phrohdoh, Georgii Dolzhykov, ExE Boss, Thundercraft5, roshal and Pyprohly
Just out of curiosity, what are people doing to get around this? Is the solution still to just disable trailing commas for your entire project, because of this issue?
but this is how prettier formats this code, it doesn't seem to be able to format it otherwise.
It seems like the prettier team decided that all types should have trailing commas (if formatting is set to all), but this just seems to be conflicting here? (prettier/prettier#6198)
Activity
Implement optional trailing commas
Implement optional trailing commas
brainkim commentedon Aug 1, 2018
Copying another code example into this issue cuz Mohamed Hegazy (@mhegazy) says it’s related and my issue was closed:
also incorrectly throws a
Trailing comma not allowederror.bensaufley commentedon Sep 5, 2018
In response to #25939:
How can I and/or the community demonstrate interest?
I think "looks like an error" / "looks pretty gross" are pretty subjective and contrary to the widely-adopted Airbnb styles, which prefer trailing commas on multiline lists, etc—to be honest, I used to be opposed to it but since we've adopted the Airbnb styles, they've grown on me, especially in that they can make Git diffing much more readable.
Disallowing them in this particular case ends up having the effect that trailing commas can be used everywhere but one place in our code, and also ends up putting our linter config at odds with ts (or makes us disable the linter for this style, which means we can't be consistent elsewhere).
I entirely understand that there are complications that can arise from implementing this, including the "what if" listed, but I think it's worth reconsidering.
alangpierce commentedon Sep 6, 2018
My mental modal of trailing commas is that trailing commas are now allowed in all cases in JS, and I think that's a lot simpler than having to remember which syntax cases support them and which don't. Previously, the language had some opinions on when they should and should not be used, but now I believe they're consistently allowed in all comma-separated lists (arrays, objects, destructures, imports, exports, parameters, and arguments, though technically not after rest elements), and it's up to the community and the tools to decide if and when to use them. The benefit (described at https://github.com/tc39/proposal-trailing-function-commas ) is relatively minor, and it can be a source of inconsistency, but with tools like Prettier, you get the benefit for free without having to think about it, so I personally have a slight preference for trailing commas everywhere so that you get slightly cleaner diffs.
I usually assume that TypeScript is consistent with JavaScript in its design decisions (and it usually is), so I was surprised to learn that trailing commas were mysteriously disallowed in this one case. Obviously it's not going to be a huge roadblock for anyone, and multiline type argument lists are super-rare anyway, but I think consistent rules mean a little less cognitive overhead.
Put another way, I think the two most reasonable coding styles are "never use trailing commas ever" and "always use trailing commas for multiline lists". That second one is now possible in JS as of ES2017, but it's still not possible in TS due to this one disallowed case.
dsherret commentedon Mar 23, 2020
Perhaps this title should be updated to "Allow trailing commas in type arguments" since this seems to be the canonical issue for this? This seems to apply to all type arguments (but not type parameters).
[-]Allow trailing commas in new expression type argument lists[/-][+]Allow trailing commas in type arguments[/+]Floriferous commentedon Apr 26, 2025
Just out of curiosity, what are people doing to get around this? Is the solution still to just disable trailing commas for your entire project, because of this issue?
This code is invalid for example:
but this is how prettier formats this code, it doesn't seem to be able to format it otherwise.
It seems like the prettier team decided that all types should have trailing commas (if formatting is set to
all), but this just seems to be conflicting here? (prettier/prettier#6198)