New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Destructuring function overloads with strictNullChecks produces invalid .d.ts #10078
Comments
Definitely looks like a bug.
I actually agree, and that was our original intent. However, a key issue is that we have no good parameter name to substitute in place of a destructuring pattern. You'd end up with auto-generated names like |
@sheetalkamat can you take a look? Thanks! |
…en deciding type for binding element in it Fixes #10078
Change __private_types fields form foo?: T, to foo: T, otherwise typeof foo would be T | undefined. Due to TS bug microsoft/TypeScript#10078 some types have to be temporary set to any in order to produce valid .d.ts files.
Change __private_types__ fields from `foo?: T`, to `foo: T`, otherwise typeof foo would be `T | undefined`. Due to TS bug microsoft/TypeScript#10078 some types have to be temporary set to `any` in order to produce valid .d.ts files.
Change __private_types__ fields from `foo?: T`, to `foo: T`, otherwise typeof foo would be `T | undefined`. Due to TS bug microsoft/TypeScript#10078 some types have to be temporary set to `any` in order to produce valid .d.ts files.
I'm using TS 2.21, when StrickNullChecks turned on, same thing happened to angular 4.0rc1 in file @angular\forms\typings\src\model.d.ts. TypeScript generates following code that causes compile error TS2459 (has no property 'x' and no string index signature) |
Fix #16357 Workaround for microsoft/TypeScript#10078 Closes #16389 PR Close #16389
Previously the RequestOptions/ResponseOptions classes had constructors with a destructured argument hash (represented by the {Request,Response}OptionsArgs type). This type consists entirely of optional members. This produces a .d.ts file which includes the constructor declaration: constructor({param, otherParam}?: OptionsArgs); However, this declaration doesn't type-check properly. TypeScript determines the actual type of the hash parameter to be OptionsArgs | undefined, which it then concludes does not have a `param` or `otherParam` member. This is a bug in TypeScript ( microsoft/TypeScript#10078 ). As a workaround, destructuring is moved inside the method, where it does not produce broken artifacts in the .d.ts. Fixes angular#16663.
Previously the RequestOptions/ResponseOptions classes had constructors with a destructured argument hash (represented by the {Request,Response}OptionsArgs type). This type consists entirely of optional members. This produces a .d.ts file which includes the constructor declaration: constructor({param, otherParam}?: OptionsArgs); However, this declaration doesn't type-check properly. TypeScript determines the actual type of the hash parameter to be OptionsArgs | undefined, which it then concludes does not have a `param` or `otherParam` member. This is a bug in TypeScript ( microsoft/TypeScript#10078 ). As a workaround, destructuring is moved inside the method, where it does not produce broken artifacts in the .d.ts. Fixes #16663.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Fix angular#16357 Workaround for microsoft/TypeScript#10078 Closes angular#16389 PR Close angular#16389
Previously the RequestOptions/ResponseOptions classes had constructors with a destructured argument hash (represented by the {Request,Response}OptionsArgs type). This type consists entirely of optional members. This produces a .d.ts file which includes the constructor declaration: constructor({param, otherParam}?: OptionsArgs); However, this declaration doesn't type-check properly. TypeScript determines the actual type of the hash parameter to be OptionsArgs | undefined, which it then concludes does not have a `param` or `otherParam` member. This is a bug in TypeScript ( microsoft/TypeScript#10078 ). As a workaround, destructuring is moved inside the method, where it does not produce broken artifacts in the .d.ts. Fixes angular#16663.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Fix angular#16357 Workaround for microsoft/TypeScript#10078 Closes angular#16389 PR Close angular#16389
Previously the RequestOptions/ResponseOptions classes had constructors with a destructured argument hash (represented by the {Request,Response}OptionsArgs type). This type consists entirely of optional members. This produces a .d.ts file which includes the constructor declaration: constructor({param, otherParam}?: OptionsArgs); However, this declaration doesn't type-check properly. TypeScript determines the actual type of the hash parameter to be OptionsArgs | undefined, which it then concludes does not have a `param` or `otherParam` member. This is a bug in TypeScript ( microsoft/TypeScript#10078 ). As a workaround, destructuring is moved inside the method, where it does not produce broken artifacts in the .d.ts. Fixes angular#16663.
Destructuring of the form: function foo({a, b}: {a?, b?} = {}) breaks strictNullChecks, due to the TypeScript bug microsoft/TypeScript#10078. This change eliminates usage of destructuring in function argument lists in cases where it would leak into the public API .d.ts.
Just hit this as per apollographql/apollo-link-state#158 Workaround for now is to just destructure inside the function body instead of in the function arguments, but that essentially means that any library that exposes typings and use destructuring + defaults in function arguments will break strict nulls. That's kind of serious, especially since it seems to happen in typings that are very difficult to override in an app's custom .d.ts files. |
This seems to be fixed in latest build |
TypeScript Version: Version 2.1.0-dev.20160801
Code
with
strictNullChecks
the code is accepted and the following .d.ts producedExpected behavior:
Since the original code is accepted, the .d.ts file should also be accepted.
Actual behavior:
When passed to tsc with
strictNullChecks
the .d.ts in question produces the errorConfusingly, if you removed the inheritance the signature for
B
is accepted.In general, I am surprised that TypeScript keeps any mention of destructuring in the .d.ts. In my mind that is part of the implementation of the function and has no relevance to the function signature. What would happen if TS plainly emits -
f(a?: {x?: boolean;}): void;
.The text was updated successfully, but these errors were encountered: