Nameless @typedef has implicit any error on the associated identifier

[TimvdLippe]

TypeScript Version: 3.7.5

Search Terms: typedef, jsdoc, noImplicitAny

Code

/**
 * @typedef {!{data: number}}
 */
export let EventTargetEvent;

Expected behavior:
No error when compiling with noImplicitAny

Actual behavior:
Variable 'EventTargetEvent' implicitly has an 'any' type.
Playground Link: https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=2&pc=22#code/PQKhCgAIUgBAXAngBwKYBNUDNIG8CEu6AhvMQFyQB2ArgLYBGqATgL6tQjDioAeyAe2bxIAG1QiAogDdUVeABVizAOYSZc+AG4gA

Related Issues: Originally discussed with @sandersn in #19983 who requested a separate issue

[sandersn]

Currently the error is correct, since the value EventTargetEvent actually does have the type any. The best way to fix this is to decide what type it should have. If I remember correctly, though, Closure code often has initialisers on declarations such that the value has a different type than the type.

@TimvdLippe is there closure code of the form

/** @typedef {{ x: number }} */
export let T = class {
}

where the class does not have an x property? An even smaller example would be export let T = 1, but I don't think I've seen that.

[TimvdLippe]

All @typedef that we have, have no initializer. Trying to add an initializer results in the following error:

[JSC_TYPE_MISMATCH] assignment
found   : null
required: None
Components._LinkInfo = null;

[TimvdLippe]

I looked at the implementation of the compiler and it seems rather straightforward to fix this. E.g. it would check, during variable initialization, if the jsdoc has a typedef. If so, set the variable to unknown, as usages of a variable with a typedef is illegal (but you should still be able to refer to it in jsdoc).

Do you mind if I try to create a PR for this issue with the above semantics?

[TimvdLippe]

WIP PR at #36454 which passes all tests.

[RyanCavanaugh]

@sandersn what's the desired behavior?

[sandersn]

• I think Infer typedef variable declaration to never #36454, which sets the type to never, is pretty good because it makes it hard to use.
• You could make value-space usage completely illegal, but this is stricter than our other JS handling.
• The current behaviour of any is not too bad either, just annoying in the case that noImplicitAny is on. It means that nameless typedefs will always have an implicit any error, with the only workaround being to add a name.

I don't think this bug is worth fixing, though, because the new code only benefits (1) closure code bases (2) with noImplicitAny: true. I don't believe there are many of these. I don't think that justifies the support cost of the new code.

[TimvdLippe]

Please note that named typedefs are not supported by Closure: https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520SIMPLE_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250A%252F%252F%2520ADD%2520YOUR%2520CODE%2520HERE%250A%252F**%2520%2540typedef%2520%257B%257Bfoo%253A%2520number%257D%257D%2520FooType%2520*%252F%250A%250A%252F**%2520%2540type%2520%257B!FooType%257D%2520*%252F%250Aconst%2520foo%2520%253D%2520%257Bfoo%253A%25205%257D%253B%250A%250A%252F%252F%2520This%2520should%2520produce%2520an%2520error%252C%2520but%2520Closure%2520does%2520not%2520support%2520named%2520typedefs%250A%252F**%2520%2540type%2520%257B!FooType%257D%2520*%252F%250Aconst%2520notfoo%2520%253D%2520%257Bfoo%253A%2520%2522%2522%257D%253B%250A%250A Named typedefs therefore can't be used as a workaround and thus it would not be possible to write code that is type-checkable by both TS and Closure.

[sandersn]

Looks like #28162 includes the error I suggested, plus a lot more, already.

[sandersn]

I still don't think this bug is worth fixing, for the same reason I gave before: compiling closure code bases with noImplicitAny: true is not a scenario that we've planned for. Instead I think it's better to convert to TS with noImplicitAny: false, and then follow up by turning on strict flags one at a time. Alternatively, automatic insertion of // @ts-ignore SEARCHABLE REASON HERE will squelch the errors until the conversion is done.