Repository navigation
JSDoc missing syntax for new Map<string, string>() #38876
Description
TypeScript Version: 3.7.x-dev.201xxxxx
Search Terms: JSDoc Map generics assignment any unsafe
Code
class MyServer {
constructor () {
// new Map is Map<any, any>; cannot call Map constructor with new Map<string, string[]>
/** @type {Map<string, string[]>} */
this.functions = new Map()
}
}
const myServer = new MyServer()
myServer.functions.get('foo')Expected behavior:
Expected to be able to say what the Map contains when creating a new map. In typescript you can do new Map<string, string[]>() but theres no explicit generic parameter function invocation syntax for JSDoc
Actual behavior:
The type Map<any, any> exists. This fails the eslint rule of no-unsafe-assignment and this fails the no-any rule of tslint etc.
Note that doing something similar for arrays works because there's a special case inference for [] and it also works for Set because the constructor is defined differently and it has generic inference in the initialization statement.
Related Issues: Yes, in eslint typescript-eslint/typescript-eslint#2109
Activity
DanielRosenwasser commentedon Jun 3, 2020
I think the thing you're encountering has more to do with the fact that we don't look at the contextual types during inference for any invocation expression except for ordinary calls. For example, this works:
DanielRosenwasser commentedon Jun 3, 2020
Though it really depends on the problem we're trying to solve. In this case, I think this would be fixed by broadening our inference process, but it's definitely the case that you can't explicitly pass type arguments in JS files.
Raynos commentedon Jun 3, 2020
I think that would be a good solution for
new Map()and alsonew Array()( Although fornew Array()you can use[]and the inference does work ).I understand that inference is not perfect in TypeScript and that being explicit is always an option when inference does not work.
Unfortunately the explicit syntax does not exist for JS files when it comes to type arguments.
I can't think of anything other then
This a little strange, but I would prefer strange and possible over impossible.