JSDoc Typedef should pull name from attached property if missing

[weswigham]

TypeScript Version: 2.7.0-dev.201xxxxx

Code

/** @typedef {{ title: string, colors: !Array.<string>, mutable: boolean }} */
ColorPicker.Spectrum.Palette;

// ...later
ColorPicker.Spectrum.PaletteGenerator = class {
  /**
   * @param {function(!ColorPicker.Spectrum.Palette)} callback
   */
  constructor(callback) {
    this._callback = callback;
    /** @type {!Map.<string, number>} */
    this._frequencyMap = new Map();
    var stylesheetPromises = [];
    for (var cssModel of SDK.targetManager.models(SDK.CSSModel)) {
      for (var stylesheet of cssModel.allStyleSheets())
        stylesheetPromises.push(this._processStylesheet(stylesheet));
    }
    Promise.all(stylesheetPromises).catchException(null).then(this._finish.bind(this));
  }
}

Expected behavior:
ColorPicker.Spectrum.Palette is effectively a type alias for the type in the typedef.

Actual behavior:

front_end/color_picker/Spectrum.js(836,77): error TS1003: Identifier expected.

(A parse error on the trailing * of the typedef).

This is used everywhere in the chrome devtools codebase.

[TimvdLippe]

I just discovered this issue while trying to migrate DevTools to TypeScript. The following piece of code triggers the Variable 'EventTargetEvent' implicitly has an 'any' type. error

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

Per https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc I have tried the following, but Closure does not accept this syntax:

/**
 * @typedef {!{data: *}} EventTargetEvent
 */

Could typedefs use the name of the variable declaration it is attached to if you don't specify your own name?

[sandersn]

@TimvdLippe what are the intended semantics? Here is what works in Typescript today:

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

/** @type {EventTargetEvent} */
var x

x.data

Here, data is defined, and of type number. I think the remaining problem is that there is a noImplicitAny error on EventTargetEvent, right? Or is it that EventTargetEvent is later used as a value, and should have the type EventTargetEvent when used as such?

[TimvdLippe]

I think you are correct. I don't see any type issues per-se when we use EventTargetEvent, so it might just be that the noImplicitAny rule could be enhanced for type-defs.

I just tested the following code and it resulted in the error below (which is probably WAI, it is just a bit hard to spot which errors are correct and which aren't, as TS reports quite a lot of errors atm on existing code):

/**
 * @typedef {!{eventTarget: !Common.EventTarget, eventType: (string|symbol), thisObject: (!Object|undefined), listener: function(!Common.Event)}}
 */
export let EventDescriptor;

/** @type {!EventDescriptor} */
var x = {
  eventTarget: 5,
};

Type '{ eventTarget: number; }' is missing the following properties from type '{ eventTarget: any; eventType: string | symbol; thisObject: Object | undefined; listener: (arg0: any) => any; }': eventType, thisObject, listener

Should I open a separate issue for noImplicitAny?

P.S. Thanks for responding so quickly!

[sandersn]

Yes, please. When designing checkJS, we thought people would not be using noImplicitAny because it would just be a quick // @ts-check at the top of a file or two. Even in the past couple of years, our model has been a project like webpack, which, while written in Javascript, is written with Typescript compilation in mind.

re response time: You are the beneficiary of my new year's resolution to look at my GH notifications instead of shuddering and shying away!

[sandersn]

This particular issue is fixed now, I believe by @weswigham a few months ago.

[TimvdLippe]

To answer the noImplicitAny question: we want to turn TypeScript strict mode to catch issues that Closure hasn't caught up to this point. noImplicitAny has already caught several issues with missing or plain out wrong types. It is one of the reasons for doing the migration to TypeScript and we are pleased with how thorough it is at finding issues.