Skip to content

Destructuring with rename incorrectly inferred as any #38969

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

Closed
remcohaszing opened this issue Jun 7, 2020 · 0 comments · Fixed by #39081
Closed

Destructuring with rename incorrectly inferred as any #38969

remcohaszing opened this issue Jun 7, 2020 · 0 comments · Fixed by #39081
Assignees
Labels
Bug A bug in TypeScript

Comments

@remcohaszing
Copy link

remcohaszing commented Jun 7, 2020

TypeScript Version: Nightly or 3.9.x

Search Terms: never destructure

Expected behavior: The type of shouldBeNever is never.

Actual behavior: The type of shouldBeNever is any.

The issue also exists for synchronous functions, but the asynchronous example shows that everything works as expected when using Promise.then().

The same issue exists for unknown as well.

Code

interface AxiosResponse<T = never> { 
    data: T;
}

declare function get<T = never, R = AxiosResponse<T>>(): Promise<R>;

async function main() {
    // These work examples as expected
    get().then((response) => { 
        // body is never
        const body = response.data;
    })
    get().then(({ data }) => { 
        // data is never
    })
    const response = await get()
    // body is never
    const body = response.data;
    // data is never
    const { data } = await get<never>();

    // The following does not work as expected.
    // shouldBeNever should be never, but is any
    const { data: shouldBeNever } = await get();
}
Output
"use strict";
async function main() {
    // These work examples as expected
    get().then((response) => {
        // body is never
        const body = response.data;
    });
    get().then(({ data }) => {
        // data is never
    });
    const response = await get();
    // body is never
    const body = response.data;
    // data is never
    const { data } = await get();
    // The following does not work as expected.
    // shouldBeNever should be never, but is any
    const { data: shouldBeNever } = await get();
}
Compiler Options
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Playground Link: Provided

@remcohaszing remcohaszing changed the title Invalid Default type never gets cast to any in specific situation. Jun 7, 2020
remcohaszing added a commit to remcohaszing/axios that referenced this issue Jun 7, 2020
This requires TypeScript users to explicitly define the type of the data they
are consuming.

Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.

Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.

The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.

`data` is still `any` in the very specific use case mentioned in
microsoft/TypeScript#38969
@RyanCavanaugh RyanCavanaugh added the Bug A bug in TypeScript label Jun 10, 2020
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 4.0 milestone Jun 10, 2020
@RyanCavanaugh RyanCavanaugh changed the title Default type never gets cast to any in specific situation. Destructuring with rename incorrectly inferred as any Jun 10, 2020
jasonsaayman added a commit to axios/axios that referenced this issue Sep 5, 2021
This requires TypeScript users to explicitly define the type of the data they
are consuming.

Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.

Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.

The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.

`data` is still `any` in the very specific use case mentioned in
microsoft/TypeScript#38969

Co-authored-by: Jay <[email protected]>
mbargiel pushed a commit to mbargiel/axios that referenced this issue Jan 27, 2022
This requires TypeScript users to explicitly define the type of the data they
are consuming.

Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.

Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.

The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.

`data` is still `any` in the very specific use case mentioned in
microsoft/TypeScript#38969

Co-authored-by: Jay <[email protected]>
redsky030511 added a commit to redsky030511/axios-server that referenced this issue May 13, 2024
This requires TypeScript users to explicitly define the type of the data they
are consuming.

Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.

Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.

The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.

`data` is still `any` in the very specific use case mentioned in
microsoft/TypeScript#38969

Co-authored-by: Jay <[email protected]>
Jupev6 added a commit to Jupev6/axios that referenced this issue Aug 11, 2024
This requires TypeScript users to explicitly define the type of the data they
are consuming.

Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.

Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.

The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.

`data` is still `any` in the very specific use case mentioned in
microsoft/TypeScript#38969

Co-authored-by: Jay <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants