JavaScript: default parameter causes type to be incorrectly inferred
See original GitHub issueFrom https://github.com/Microsoft/vscode/issues/62013
TypeScript Version: 3.2.0-dev.20181027
Search Terms:
Code For the javascript:
var SomeObject = {
SomeFunction: function (SomeInput) {
return SomeInput * 2;
},
SomeOtherFunction: function (SomeOtherInput, SomeOptionalInput = SomeObject.SomeFunction(2)) {
return SomeOtherInput * SomeOptionalInput;
}
};
SomeObject
Hover over SomeObject
Bug:
Type is any
. If the default parameter is removed then the type is correct
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:6 (5 by maintainers)
Top Results From Across the Web
TypeScript parameter type inference failure - Stack Overflow
Whenever I see a requirement to have function type that depends on argument values, "use overloads" is the first thing that comes to...
Read more >Infer callback parameters that has default values · Issue #48934
Your callback function, lacking parameter type annotations, is context sensitive, which means the types flow in from useCallback . If there was ...
Read more >Default parameters - JavaScript - MDN Web Docs
Default function parameters allow named parameters to be initialized with default values if no value or undefined is passed.
Read more >PhpStorm - Code Inspections in JavaScript and TypeScript
Reports a function call with a parameter, return value, or assigned expression or incorrect type, if the context symbol can be implicitly ...
Read more >Documentation - Narrowing - TypeScript
Argument of type 'string | number' is not assignable to parameter of type ... But it turns out that in JavaScript, typeof null...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
It looks like something causes us to pull on the signature type early which, with the initializer, depends on the object type itself and causes it to get marked as circular, specifically with
noImplicitAny
on, we get theerror. Thing is, if you wrote the same thing in a more namespace-y way:
we do waaaaaaaay better, even though the two are pretty much equivalent in this case. I think that technically this is working as intended; but for the sake of our JS users, we could do better here.
Errr…
noImplicitAny
?noImplicitThis
?