Skip to content

[NewErrors] 4.5.0-dev.20210912 vs 4.4.3 #45846

Description

The following errors were reported by 4.5.0-dev.20210912, but not by 4.4.3

microsoft/vscode

2 of 51 projects failed to build with the old tsc

extensions/github/tsconfig.json

  • error TS2339: Property 'pulls' does not exist on type '({ [x: string]: any; } & { [x: string]: any; } & Octokit & void & { paginate: PaginateInterface; } & RestEndpointMethods) | ReposCreateForkResponseData'.

src/tsconfig.json

src/tsconfig.monaco.json

src/tsconfig.tsec.json

reduxjs/react-redux

test/typetests/tsconfig.json

  • error TS2322: Type 'Context<ReactReduxContextValue<any, AnyAction> | null> | MutableRefObject<unknown> | ((instance: unknown) => void) | Omit<...>' is not assignable to type 'Context<ReactReduxContextValue<any, AnyAction> | null>'.
  • error TS2339: Property 'Consumer' does not exist on type 'Context<ReactReduxContextValue<any, AnyAction> | null> | MutableRefObject<unknown> | ((instance: unknown) => void) | Omit<...>'.

tsconfig.json

  • error TS2322: Type 'Context<ReactReduxContextValue<any, AnyAction> | null> | MutableRefObject<unknown> | ((instance: unknown) => void) | Omit<...>' is not assignable to type 'Context<ReactReduxContextValue<any, AnyAction> | null>'.
  • error TS2339: Property 'Consumer' does not exist on type 'Context<ReactReduxContextValue<any, AnyAction> | null> | MutableRefObject<unknown> | ((instance: unknown) => void) | Omit<...>'.

youzan/vant

2 of 9 projects failed to build with the old tsc

packages/create-vant-cli-app/tsconfig.json

lensapp/lens

4 of 5 projects failed to build with the old tsc

tsconfig.json

Activity

  1. andrewbranch commented on Sep 13, 2021

    @andrewbranch
    Member

    Most of these are from #45350—Ron Buckton (@rbuckton), you’ll probably want to take a look at some of the assignability errors mentioning Awaited. There are a couple type argument issues but those seem trivial to fix. It’s more important to understand the others and see if they have easy fixes too.

  2. rbuckton commented on Sep 16, 2021

    @rbuckton
    Contributor

    Regarding extensions/github/src/pushErrorHandler.ts#L106: It looks like the call to withProgress at line 32 was previously returning a tuple type of [Octokit, ReposCreateForkResponseData], but is now returning (Octokit | ReposCreateForkResponseData)[]. If we were previously inferring a tuple here, but aren't due to the change to await then that's definitely a bug.

  3. rbuckton commented on Sep 16, 2021

    @rbuckton
    Contributor

    It looks like extensions/github/src/pushErrorHandler.ts#L106 is due to #45719 since we're no longer inferring the type arguments as a tuple due to the binding pattern.

  4. rbuckton commented on Sep 16, 2021

    @rbuckton
    Contributor
  5. rbuckton commented on Sep 17, 2021

    @rbuckton
    Contributor

    Matt Bierner (@mjbvz) I saw that you updated pushErrorHandler.ts for TS 4.5 using an as any on line 107

    I would recommend you add as const on line 85 instead to preserve type safety. We are no longer treating untyped binding patterns as type argument inference sources as of #45719.

  6. mjbvz commented on Sep 17, 2021

    @mjbvz

    Ron Buckton (@rbuckton) Ah nice! Just made the change. Thanks for the help as I was super confused by the error

  7. rbuckton commented on Sep 17, 2021

    @rbuckton
    Contributor

    For youzan/vant:

    For lensapp/lens:

  8. rbuckton commented on Sep 17, 2021

    @rbuckton
    Contributor

    I'm unsure as to the cause of the errors in react-redux, but they don't seem to be due to await->Awaited<T> change as far as I can tell.

  9. rbuckton commented on Sep 17, 2021

    @rbuckton
    Contributor

    Ah, the issue with react-redux is also due to #45719:

    image

    We're no longer inferring a tuple type for the return statement because we don't infer a contextual type from the binding pattern. This seems like an unfortunate loss due to that change:

    declare const f: <T>(cb: () => T) => T;
    const [a, b, c] = f(() => [1, "hi", true]);

    image

    vs

    image

  10. andrewbranch commented on Sep 17, 2021

    @andrewbranch
    Member

    Hm, there are so many cases where binding patterns as an inference source are so bad, but these tuple cases are kind of disappointing. Maybe I can bring that back for tuples. It's a lot more suspicious to say that an object binding pattern implies the presence of some properties on an otherwise unknown type than it is to say that an array binding pattern implies that an array literal should be interpreted as a tuple.

  11. andrewbranch commented on Sep 23, 2021

    @andrewbranch
    Member

    Ron fixed the Awaited issues and I rolled back the binding pattern changes for now (see design notes linked above). Matt Bierner (@mjbvz), you should be able to roll back the as const changes you had to do if you want.

  12. locked as resolved and limited conversation to collaborators on Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions