Skip to content

[NewErrors] 4.8.0-dev.20220609 vs 4.7.3 #49460

Closed as not planned
Closed as not planned

Description

The following errors were reported by 4.8.0-dev.20220609, but not by 4.7.3

kamranahmedse/developer-roadmap

tsconfig.json

  • error TS2344: Type 'K' does not satisfy the constraint 'Record<string, any>'.
    • file:///mnt/ts_downloads/developer-roadmap/node_modules/@chakra-ui/descendant/src/use-descendant.ts#L11
    • file:///mnt/ts_downloads/developer-roadmap/node_modules/@chakra-ui/descendant/src/use-descendant.ts#L87
    • file:///mnt/ts_downloads/developer-roadmap/node_modules/@chakra-ui/descendant/src/use-descendant.ts#L91

coder/code-server

7 of 57 projects failed to build with the old tsc

src/tsconfig.monaco.json

src/tsconfig.tsec.json

microsoft/playwright

4 of 9 projects failed to build with the old tsc

packages/html-reporter/tsconfig.json

vercel/hyper

2 of 3 projects failed to build with the old tsc

tsconfig.json

  • error TS2344: Type 'BaseType' does not satisfy the constraint 'Record<string | number, any>'.
    • file:///mnt/ts_downloads/hyper/app/node_modules/type-fest/ts41/get.d.ts#L93 in app/tsconfig.json
    • file:///mnt/ts_downloads/hyper/app/node_modules/type-fest/ts41/get.d.ts#L94 in app/tsconfig.json
  • error TS2344: Type 'T' does not satisfy the constraint 'Record<string, any>'.
    • file:///mnt/ts_downloads/hyper/app/node_modules/conf/dist/source/types.d.ts#L201 in app/tsconfig.json

react-hook-form/react-hook-form

2 of 3 projects failed to build with the old tsc

tsconfig.json

typeorm/typeorm

tsconfig.json

mobxjs/mobx

7 of 9 projects failed to build with the old tsc

packages/mobx/tsconfig.json

palantir/blueprint

11 of 25 projects failed to build with the old tsc

packages/datetime/src/tsconfig.json

packages/select/src/tsconfig.json

apollographql/apollo-client

tsconfig.json

Activity

  1. DanielRosenwasser commented on Jun 9, 2022

    @DanielRosenwasser
    Member

    Common issue is something like

    export interface Obj {
        [key: string]: any
    }
    
    function foo<T>(x: T) {
        let y: Obj = x;
    }
  2. andrewbranch commented on Jun 9, 2022

    @andrewbranch
    Member

    TypeScript Bot (@typescript-bot) bisect good v4.7.3 bad main

  3. typescript-bot commented on Jun 9, 2022

    @typescript-bot
    ContributorAuthor

    The change between v4.7.3 and main occurred at 5aa0053.

  4. andrewbranch commented on Jun 9, 2022

    @andrewbranch
    Member

    It’s nonsense because I didn’t add // @strictNullChecks: true to the repro. But I wonder what change it thinks it picked up on, hah

  5. ahejlsberg commented on Jun 9, 2022

    @ahejlsberg
    Member

    Daniel Rosenwasser (@DanielRosenwasser) I'm pretty sure that comes from #49119 (which incorporated the change from #48366). When checking whether an unconstrained type parameter T is assignable to some type X, we used to check whether {} is assignable to X. We now check whether unknown is assignable to X, and in this case it isn't because T could be undefined or null. This seems like a very legit error.

  6. typescript-bot commented on Jun 10, 2022

    @typescript-bot
    ContributorAuthor

    👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of this repro running against the nightly TypeScript.


    Comment by Daniel Rosenwasser (@DanielRosenwasser)

    ❌ Failed: -

    • Type 'T' is not assignable to type 'Obj'.

    Historical Information
    Version Reproduction Outputs
    4.3.2, 4.4.2, 4.5.2, 4.6.2, 4.7.2

    👍 Compiled

  7. meg2208 commented on Sep 1, 2022

    @meg2208

    Is there any plan to resolve typeorm/typeorm#9331? This is a very extensively used dependency and it doesn't seem like a straightforward change to fix the issue. Is it possible the following TS change can be reverted?

    As metioned in TS 4.8 release notes linked above, T is no longer assignable to {} so it's no longer valid in ts 4.8.X because T no longer constraints ObjectLiteral.

  8. andrewbranch commented on Sep 1, 2022

    @andrewbranch
    Member

    I fixed all the typeorm errors when the change first landed, and it was very straightforward: typeorm/typeorm#9106. I guess new changes to typeorm were introduced in the meantime. They should be able to follow the same pattern and fix the new ones. I can try to send a follow-up PR tomorrow if they don’t get to it first. But no, the TS change will definitely not be reverted. The error is accurate and protects against real unsafe calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Has ReproThis issue has compiler-backed repros: https://aka.ms/ts-repros

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions