JSDoc: error TS1005 when using conditional type in @typedef

[Serega124]

TypeScript Version: 3.9.0-dev.20200229

Search Terms: JSDoc typedef

Expected behavior: compile javascript JSDoc without any errors

Actual behavior: Actually, tsc compiles correct d.ts type, but annoying error '?' expected appears. You can see that error on the Playground's Errors tab.

Related Issues:

Code

/**
 * @template T
 * @typedef {{[K in keyof T]: T[K] extends Function ? K : never}[keyof T]} FunctionProperties
 */

Compiler Options

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "esModuleInterop": true,
    "checkJs": true,
    "allowJs": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}

Playground Link: Provided

[sandersn]

The JSDoc parser supports postfix-? types instead of conditional types, based on existing support in Closure. This syntax is not common, since it's not even standard Closure. However, removing it would require checking to see how much code out there we are breaking.

[sandersn]

A grep through the user tests gives the following breakdown. The break wouldn't be that bad, but I'm not sure conditional types in JSDoc is worth the churn -- you can see that a number of widely-used projects use postfix-? types a few times each. Let's leave this open on the backlog to see if there's much demand for it.

postfix-?

eslint-scope (5)
eslint-plugin-jest (5)
nodemailer (1)
fbjs (1)
eslint (1)
wd (1?) (seems like it's an example, not a jsdoc type reference)
prettier (3)
webpack (2)
react-native (1)
svgo (1)
protobufjs (13)
grpc (1)

standalone ?

angular (100?)
puppeter (1)
zone.js (1)
react-dom (5)
react-native (2)
soap (4)
chrome-devtools-frontend (25?)
firebase (4)

Note that standalone ? should continue to work as a type, although I'd need to look at the parser code again to figure out if that's possible.

(Sorry for the annoying formatting)

[sandersn]

#38747 shows another conflict -- postfix-? in tuple types. This one looks ambiguous to humans, too.

[sandersn]

So, uh, tuple type parsing now relies on postfix-? ... So it kind of has to stay in. That means the simplest change is to keep postfix-?, but to choose the conditional type interpretation whenever it's ambiguous, even inside JSDoc.

I'll send out a PR soon.