Codecov Report

Merging#1525 intomaster willincrease coverage by<.01%.
The diff coverage is100%.

@@            Coverage Diff             @@##           master    #1525      +/-   ##==========================================+ Coverage   95.57%   95.57%   +<.01%==========================================  Files         149      149                Lines        6688     6691       +3       Branches     1915     1917       +2     ==========================================+ Hits         6392     6395       +3  Misses        112      112                Partials      184      184

Sorry for being late on this PR. In Prettier, we thought printing?NullableTypes as is was a good idea, useful for people who migrate from Flow to TS (seeprettier/prettier#7020). Otherwise, formatting wouldn't work for them until they eliminate this syntax in the entire file. Can we probably somehow still allow this specific type (TSJSDocNullableType) of node in the AST?

hmm, thats good point, main reason for this PR was fixing syntaxvar a: function(b): c;,JSDocFunctionType,

i'm in conflict now, i don't want to produce that broken ast, but i want to support it at same time.

i think we could support it, but we will have to prepare some tests (as to not crash because of it anymore)

I'm asking specifically aboutTSJSDocNullableType only. It didn't cause any crashes, did it? Having the AST, TypeScript ESLint could even introduce a rule that would autofix it into... | null | undefined.

The rest of the JSDoc types are of no interest. At least for now. We might meet them again though if one day Prettier decides to format JSDoc, but this is a completely different story.

that's good idea, i will take a look, and prepare POC latter today,
thanks for your feedback

from my research it seems that only few jdoc nodes can actually appear in types.
typescript uses this file to validate them:https://github.com/microsoft/TypeScript/blob/master/tests/baselines/reference/jsdocDisallowedInTypescript.js

JSDocAllType = '*'
JSDocUnknownType = '?'
JSDocNonNullableType = '!xxxx' | 'xxxx!'
JSDocNullableType = '?xxxx' | 'xxxx?'

additionally before this change syntax was crashing. (JSDocFunctionType)

const x: function(new: number, string);const x: function(this: number, string);var g: function(number, number): number;

Based on@thorn0's suggestion of "people who migrate from Flow to TS"
I think we only need to support:

• JSDocAllType
  • The (deprecated) flow existential type
• JSDocNullableType
  • Flow maybe type
  • we could go a step further and only allowJSDocNullableType with a leading question mark (?foo, notfoo?).

both syntaxes leading and trailing are generating currently same node (position is no preserved),

i started writing rule for this, i will push this soon (and ofc i revert this commit and fixed issue)

my only question is what node type we should use for them? maybe we should just keep those auto-generated names

Yeah they can fall into the "unknown node bucket" which just prependsTS.
I wouldn't revert this commit - just submit a new one that excludes those two from the range.