You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Generic function with function as argument autocomplete broken, unless generic argument of the argument function is it's first argument #60648
typescript generic function no autocomplete function as argument
🕗 Version & Regression Information
Relevant versions are 5.4.5 and above, tested in all versions from 5.4.5 to 5.8.0 (Nightly) inclusive, I was able to reproduce the bug in all versions.
asyncfunctionregisterPluginBad<OptextendsRecord<string,any>>(callback: (app: any,options: Opt)=>void,opts: NoInfer<Opt>): Promise<void>{}registerPluginBad((app,opts: {something: string})=>{},{// below autocomplete is broken, even though the type is properly validated
some
});// interestingly, autocomplete works if "options" argument comes first, for example:asyncfunctionregisterPluginGood<OptextendsRecord<string,any>>(callback: (options: Opt,app: any)=>void,opts: NoInfer<Opt>): Promise<void>{}registerPluginGood((opts: {something: string},app: any)=>{},{// below autocomplete works
some
});
🙁 Actual behavior
This one has to be tested in the playground:
registerPluginBad - second argument does not autocomplete, however type is properly validated
registerPluginGood - exact same function, except the first argument "callback" arguments have changed the order, which for some reason fixes the autocomplete
🙂 Expected behavior
For both functions, autocomplete should work. Argument order should not matter.
Both do not infer from "opts", so any inference should be from "options" argument of the callback.
The problem here is not that the order of the parameters and arguments is different. Your registerPluginGood call annotates both parameters of the callback. This makes it context-insensitive, and it can, thanks to that, hit different inference paths.
It happens that one of my old PRs addresses this: #56460
Activity
Andarist commentedon Dec 2, 2024
The problem here is not that the order of the parameters and arguments is different. Your
registerPluginGoodcall annotates both parameters of the callback. This makes it context-insensitive, and it can, thanks to that, hit different inference paths.It happens that one of my old PRs addresses this: #56460