Generic types from JSDoc aren't really generic

/**
 * @constructor
 * @template {string} K
 * @template V
 */
function Multimap() {
    /** @type {Object<string, V>} TODO: Remove the prototype from the fresh object */
    this._map = {};
};

var Ns = {}
/** @type {Multimap<"a" | "b", number>} */
const map = new Multimap();
const n = map._map['hi']

Expected behavior: n: number

Actual behavior: n: any in 3.0; n: V in 3.1-dev.

Types resolved from functions are never properly generic, even that function has @template-specified type parameters; they’re only special-cased in a few places to produce a specific instantiation of a type. They should use the normal generic type machinery that Typescript does.

[LAC-Tech]

We do not have general plans to replicate all of TS’s features in JS, since we think that most people who want TS’ features will eventually switch to TS anyway. The main user we care about for JSDoc is the one who never thinks about TS, or types for that matter.

I get that you have to prioritise, but it’s sad to hear.

I strongly prefer to write Javascript instead of Typescript just because it removes a building step. But I still “think about types”.

For me it’s about setting up simpler projects with less moving parts.

[michaelolof]

Thank you for replying.

I kind of understand where you’re coming from and I can probably tell this pattern is definitely not conventional.

My issue with the JSDoc approach, is that it can get really verbose. The above example is a very simple use case for generics.

Consider a typed pipe function like this in a typescript file.

export function pipe<T1, R>(
  fn1: (arg1: T1) => R,
  ...fns: Array<(a: R) => R>
): (arg1: T1) => R;

export function pipe<T1, T2, R>(
  fn1: (arg1: T1, arg2: T2) => R,
  ...fns: Array<(a: R) => R>
): (arg1: T1, arg2: T2) => R;

export function pipe<T1, T2, T3, R>(
  fn1: (arg1: T1, arg2: T2, arg3: T3) => R,
  ...fns: Array<(a: R) => R>
): (arg1: T1, arg2: T2, arg3: T3) => R;

export function pipe<T1, T2, T3, T4, R>(
  fn1: (arg1: T1, arg2: T2, arg3: T3, arg4: T4) => R,
  ...fns: Array<(a: R) => R>
): (arg1: T1, arg2: T2, arg3: T3, arg4: T4) => R;

export function pipe<R>(
  fn1: (...args: any[]) => R,
  ...fns: Array<(a: R) => R>
): (a: R) => R {
  return fns.reduce((prevFn, nextFn) => value => nextFn(prevFn(value)), fn1);
}

I shudder to think of how this would be implemented with JSDoc. Even the TypeScript approach is still a bit to noisy. I’m in an environment where my team is still warming up to TypeScript and I’m scared seeing something like this could easily put them off.

For me i believe the biggest benefit of this .d.ts approach is hiding away all the noise that comes with complicated typings like this. There’s also the advantage of seamlessly sharing interfaces extending interfaces etc. without JSDocing your entire codebase.

Also you have to consider this is an approach that works already in TypeScript. It just breaks when using generics.

I hope you do consider it.

Great job with all the work @typescript.