Using @satisfies tag in JSDoc has strange effects on arrow function parameters

[jespertheend]

🔎 Search Terms

jsdoc satisfies

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about satisfies

⏯ Playground Link

https://www.typescriptlang.org/play?strictNullChecks=true&filetype=js#code/PQKhAIAEGcEMBcCW0BmiCm1wG8AUBXfRAEwC5xp4AnRAOwHMBKcAXgD5wA3AexIF9wIYACgAxt1qVwAWwCeAMXy1RSCa3CESrDtj7DhoCJHiyADumLoUOAAqwqsaenjoq0ADwnz3a3MXLVWjYBeW5uQRFgYHAY2Lj4hMSkxIA9NINo5Ky4gAluTldwfMKAA1DuEvBYWmIigCNoVwLweAALBHBEeE6sEtp0AqoS4SA

💻 Code

/** @satisfies {(uuid: string) => void} */
const myFunction = uuid => {}

/** @typedef {Parameters<typeof myFunction>} Foo */
//                                           ^^^
//                        Hover over `Foo` and observe that it is `never`

🙁 Actual behavior

Type of Foo is never.

🙂 Expected behavior

Type of Foo should be [uuid: string]

Additional information about the issue

In the playground link above I have enabled strictNullChecks, but when you disable this, the parameter becomes optional. I.e. [uuid?: string], which is still incorrect. (playground link)

For reference, the same code in TypeScript works as expected: playground link.

[Andarist]

The problem is in the getSignatureFromDeclaration and its isUntypedSignatureInJSFile check - it doesn't account for @satisfies. I'll put up a PR with a fix for this today.