Nameless @typedef has implicit any error on the associated identifier

Nathan Shively-Sanders (@sandersn)

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 Nathan Shively-Sanders (@sandersn) in #19983 who requested a separate issue

Tim van der Lippe (@TimvdLippe)

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.

Tim van der Lippe (@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.

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;

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?

Infer typedef variable declaration to `never`

WIP PR at #36454 which passes all tests.

Nathan Shively-Sanders (@sandersn)

Nathan Shively-Sanders (@sandersn) what's the desired behavior?

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.

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.

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

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.

Navigation Menu

Repository navigation

Nameless `@typedef` has implicit any error on the associated identifier #36375

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Nameless @typedef has implicit any error on the associated identifier #36375

Description

Activity

sandersn commented on Jan 23, 2020

TimvdLippe commented on Jan 23, 2020

TimvdLippe commented on Jan 26, 2020

TimvdLippe commented on Jan 27, 2020

RyanCavanaugh commented on Jan 27, 2020

sandersn commented on Jan 27, 2020

TimvdLippe commented on Jan 27, 2020

sandersn commented on Jan 28, 2020

sandersn commented on Apr 15, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Nameless `@typedef` has implicit any error on the associated identifier #36375