Diagnostic code 8030 being incorrectly generated using JSDoc `@type` on a function.

[Arashiryuu]

🔎 Search Terms

Diagnostic 8030 is being generated incorrectly when using JSDoc @type on a method when the type is being referred to from an interface. This is using the new tsc LSP - version 7.0.2.

🕗 Version & Regression Information

• This changed between versions 7.0.0-dev.260707.2 and 7.0.2.
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about new native issues being transferred into the main typescript repo.

⏯ Playground Link

No response

💻 Code

// types.ts
interface Example {
  method (): number;
}
export {};

// code.js
const exampleFns = {
  /**
   * @type {Example['method']} // A JSDoc `@type` tag on a function must have a signature with the correct number of arguments.
   */
  method () {
    return Math.random();
  }
};

🙁 Actual behavior

in this example, the diagnostic and LSP info does not tell the user that typescript is internally suffixing | undefined to the type. As such wrapping the type in NonNullable<T> removes the error diagnostic, I do not believe this to be intended behaviour as previous iterations the golang native LSP tsgo (7.0.0-dev.260707.2) did not produce this diagnostic, nor did previous versions of typescript.

🙂 Expected behavior

The type should be properly referenced with no additional suffixing of types, as it used to.

Additional information about the issue

No response

[RyanCavanaugh]

I couldn't reproduce the version boundary you describe.

With the two files exactly as posted, both 7.0.2 and 7.0.0-dev.260707.2 report the same two diagnostics, because code.js never imports Example and types.ts never exports it:

user-repro/code.js(3,13): error TS2304: Cannot find name 'Example'.
user-repro/code.js(3,13): error TS8030: A JSDoc 'Type (@type)' tag on a function must have a signature with the correct number of arguments.

Wiring the two files up in the minimal way the report implies — adding /** @import { Example } from "./types" */ to code.js and export interface Example in types.ts, leaving @type {Example['method']} unchanged — makes both 7.0.2 and 7.0.0-dev.260707.2 compile with no errors at all (tsc --allowJs --checkJs). So I don't see 8030 on 7.0.2 either.

Your description (an internal | undefined, and NonNullable<T> clearing the error) implies that in your project Example['method'] resolved to (() => number) | undefined, but the posted interface declares a required method(): number, which does not include undefined.

To investigate further, can you provide a self-contained project that shows the 8030 on 7.0.2, specifically: how Example is made visible to code.js, the exact declaration of method (is it optional?), and your tsconfig.json compiler options (e.g. exactOptionalPropertyTypes, noUncheckedIndexedAccess) that cause Example['method'] to include | undefined?

[Arashiryuu]

I use a reference comment /// <reference path="./types.ts" /> in the js file, and also declare global in the type file.
I don't have exactOptionalPropertyTypes or noUncheckedIndexAccess set in my tsconfig.json, it's very barebones.
The exact definition of the method is optional, yes.
tsconfig.json

{
	"compilerOptions": {
		"jsx": "preserve",
		"checkJs": true,
		"target": "ESNext",
		"lib": [
			"DOM",
			"ESNext"
		],
		"module": "nodenext",
		"moduleResolution": "nodenext",
		"sourceMap": false,
		"inlineSourceMap": true,
		"inlineSources": true,
		"allowJs": true,
		"rootDir": ".",
		"outDir": "dist",
		"typeRoots": [  
			"./node_modules/@types"
		]
	}
}

types.ts

declare global {
  namespace MyNS {
    interface Example {
      // ...
      // ... other methods
      // ...
      method? (): number;
    }
  }
};

export {};

code.js

/// <reference path="./types.ts" />
// @ts-check

const Example = {
  /**
   * @type {MyNS.Example['method']}
   */
  method () {
    return Math.random();
  }
};

it didn't used to resolve to (() => number) | undefined and now that it does in 7.0.2 it doesn't tell me that in the type signature when I hover the method, instead it says method(): any so to discover the | undefined I put the type into a new type and checked that. type X = MyNS.Example['method'] -> @type {X} -> read the hover info for the type, and that's where I saw the (() => number) | undefined.

I'm using the native 7.0.2 in nvim which is where I noticed this, but it goes unnoticed on 6.0.0-dev.20260416 when I open it in vscode, since past versions didn't flag it I didn't think it was intentional.

[RyanCavanaugh]

Single-file repro works. We should remove null/undefined and then contextually type, i.e. this shouldn't be an implicit any on s:

// @ts-check
/** @typedef {{ method?: (s: string) => number }} Example */

const example = {
  /** @type {Example['method']} */
  method(s) {
    return 0;
  }
};

[jyx-07]

Opened a PR for this: #64052

Root cause: Example['method'] resolves to
((s: string) => number) | undefined — the | undefined was fed
directly into signature-lookup helpers that don't handle unions,
producing the false-positive 8030 and implicit any for the parameter.

Fix: apply removeMissingOrUndefinedType at the three affected call
sites in checker.go before signature resolution, matching the pattern
already used elsewhere in the checker for the same class of problem.

Verified:

• Original repro → 0 errors
• Genuine arity mismatches still correctly report 8030
• Parameter is now correctly typed from the JSDoc annotation