Open
Labels
BugA bug in TypeScriptA bug in TypeScript
Milestone
Description
🔎 Search Terms
JSDoc Sajith Ariyarathna (@this), completions, this., checkJs, getCompletionsAtPosition, contextual this
🕗 Version & Regression Information
- Classic
typescript@6.0.3language service: completions onthis.inside a JSDoc-@this-annotated function list the annotated members - Native LS on current
main(7.1.0-dev): no completion list (nil/ empty) at the same position - Checker still applies
@thiscorrectly (e.g.this.missing→ TS2339); only completions are broken - Control: the equivalent TypeScript
thisparameter form works on native
💻 Code
// @allowJs: true
// @checkJs: true
/**
* @this {{ id: string, click: () => void }}
* @param {string} ev
*/
function h(ev) {
this./*completions here*/
}Also fails with DOM types:
// @lib: dom,es2020
/**
* @this {HTMLElement}
*/
function h() {
this./*completions here*/
}Working native control (TS this param):
function h(this: { id: string, click: () => void }, ev: string) {
this./*id, click offered*/
}Checker still sees the @this type:
/**
* @this {{ id: string, click: () => void }}
*/
function h() {
this.missing; // native + classic: TS2339
}Classic LS (6.0.3)
// getCompletionsAtPosition after `this.`
entries: ['click', 'id']Native LS
Fourslash VerifyCompletions at the this. marker: Expected completion list but got nil.
Expected behavior
Same as classic / same as a TS this parameter: offer id, click (or HTMLElement members).
Notes
Distinct from documentation API divergence (#64919) and from inlay/signature trailing-rest issues (#65162/#65165).
Metadata
Metadata
Assignees
Labels
BugA bug in TypeScriptA bug in TypeScript
Activity
timurzvural commentedon Nov 3, 2026
Broader than
@thisSame native LS hole for JSDoc
@paramtypes on JS function parameters: checker diagnostics see the type, but hover/completions treat the parameter asany.Native hover on
p:(parameter) p: anyClassic hover on
p:(parameter) p: { id: string; }Controls that work on native:
this/ parameter annotations@typeonconst/varwith an initializer (or assigned before use).jsSo the gap is specifically LS display/completions for types attached via JSDoc to parameters /
this, not all JSDoc typing.[-]Native LS: no property completions on `this.` when type comes from JSDoc `@this`[/-][+]Native LS: JSDoc `@this` / `@param` types are `any` for hover & completions (checker OK)[/+]timurzvural commentedon Nov 3, 2026
Also signature help
Call-site signature help for the same JSDoc-
@param-typed function showsanyparameters on native:f(a: string, b: number): voidf(a: any, b: any): void1-DARK commentedon Nov 4, 2026
Thanks for the detailed report. As far as I can tell this isn't an LS bug; the repro just isn't running in a JS file.
The fourslash snippets have
@allowJs/@checkJsbut no// @filename: /something.js, so the content isn't treated as JS. In TS files, JSDoc@this/@paramtypes aren't used for typing, sothis/pbeingany(and no member completions) is expected there.With an explicit JS filename, everything in this issue and the follow-up comments already works on native
main:Hover on
pshows(parameter) p: { name: string; }. I've added this as a fourslash regression test in #65307. Suggest closing as not a bug; please reopen if you can reproduce it with a real.jsfile in an editor.