Skip to content
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

Deep readonly type with a nested tuple made deep writeable incorrectly extends never #52267

Open
conorbrandon opened this issue Jan 17, 2023 · 4 comments
Labels
Needs Investigation This issue needs a team member to investigate its status.
Milestone

Comments

@conorbrandon
Copy link

conorbrandon commented Jan 17, 2023

Bug Report

🔎 Search Terms

never tuple
readonly tuple
change name of type
change result of type

🕗 Version & Regression Information

  • This changed between versions 4.4.4 (correct) and 4.5.5 (incorrect) and 4.6.4 (correct) and >= 4.7.4, <= 5.2.2 (incorrect) and 5.3.2 (correct)

⏯ Playground Link

Playground link with relevant code

💻 Code

type DeepWriteable<T> = { -readonly [P in keyof T]: DeepWriteable<T[P]> };
type IsNever<T> = [T] extends [never] ? true : false;

type DeepExactArray<Arr extends any[], Shape> = {
  [K in keyof Arr]: DeepExactShape<Arr[K], Shape[K & keyof Shape]>;
};
type DeepExactShape<Obj, Shape> =
  (
    Obj extends Shape
    ? (
      Shape extends any
      ? (
        Obj extends any[]
        ? DeepExactArray<Obj, Shape>
        : (
          IsNever<Exclude<keyof Obj, keyof Shape>> extends true
          ? (
            Obj extends object
            ? {
              [K in keyof Obj]: K extends keyof Shape ? DeepExactShape<Obj[K], Shape[K]> : never;
            }
            : Obj
          )
          : never
        )
      )
      : never
    )
    : never
  );

const obj = {
  topLevel: {
    data: {
      myTuple: [{ tup1: null, extra: '' }]
    }
  }
} as const;
type Obj = DeepWriteable<typeof obj>;
type ShapeToValidate = {
  topLevel: {
    data?: {
      myTuple: [{ tup1: null }] | null;
    };
  }
};
type ValidatedShape = DeepExactShape<Obj, ShapeToValidate>;
//   ^? { topLevel: { data: { myTuple: [never]; }; }; }
type test = Obj extends ValidatedShape ? true : false;
//    ^? type test = true;
type test2 = Obj extends { topLevel: { data: { myTuple: [never]; }; }; } ? true : false;
//    ^? type test2 = false;

const thing: test = false; // Changing the name of type test, for example, to tes, in either usage negates the type from false to true, then back to false

🙁 Actual behavior

A type with a multi-level nested tuple incorrectly extends itself but with a slight modification: the element of the tuple is replaced with never, but only when the type is created the using above DeepExactShape type. When using the same type with the never replacement, but explicitly written out instead, it correctly does not extend.

In addition, when removing the as const statement, it correctly does not extend. When changing the nested depth of the tuple from 3 to 2 (removing the topLevel property), it correctly does not extend.

Finally, when changing the name of type test, for example, to tes, in either usage negates the type from false to true, then back to false as visible in the two-slash query and when hovering over the type (in 4.7.4 and above)

🙂 Expected behavior

In both cases, the initial type, Obj, should not extend either the created type (from DeepExactShape), or the explicitly defined type, with, or without, the as const statement included.

Changing the name of a type should not result in the value of the type being different.

The degree of nesting (2 vs 3) should not change whether the type extends the created type.

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Jan 19, 2023
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jan 19, 2023
@RyanCavanaugh
Copy link
Member

A simpler demonstration of the bug here would let us look at this earlier.

@conorbrandon
Copy link
Author

conorbrandon commented Jan 20, 2023

Thanks for the comment Ryan. This is a contrived example that is exhibiting the same behavior. I'm setting a depth limit of 2 on the recursion of a basic recursive mapped type and once the limit is reached, setting the value to never. Playground

type DeepWriteable<T> = { -readonly [P in keyof T]: DeepWriteable<T[P]> };

type Mapped<T, Count extends never[] = []> = {
  [K in keyof T]: Count extends [never, never] ? never: Mapped<T[K], [...Count, never]>
};

const obj = {
  level1: {
    level2: {
      level3: { tup1: 0 }
    }
  }
} as const;
type Obj = DeepWriteable<typeof obj>;

type MappedResult = Mapped<Obj>;
type test = Obj extends MappedResult ? true : false;
//   ^? type test = true;

type RawResult = {level1: {level2: { level3: never; }; }; };
type test1 = Obj extends RawResult ? true : false;
//   ^? type test1 = false;

const thing: test = false; // Changing the name of type test, for example, to tes, in either usage negates the type from false to true, then back to false

Interestingly (and I'm not sure what the TS team's thoughts are on types like this), I was curious, just to make sure that the resulting type from the MappedResult type and the RawResult type I explicitly wrote are Equal, here is a second playground that doesn't exhibit the "renaming type causes type's value to change" behavior, with the only modification being a few extra lines at the bottom that check whether the MappedResult type and the RawResult type are equal.

@conorbrandon
Copy link
Author

conorbrandon commented Jan 20, 2023

And just to be clear on this "renaming type" behavior, this is not using the right click -> rename symbol functionality, this is

  1. literally placing the cursor at the position indicated by the underscore character in the line below:
    const thing: test_ = false;
  2. Press backspace.
  3. The two slash query result (and hovering over) of type test = ... changes from true to false.

@conorbrandon
Copy link
Author

This is (again) now fixed in 5.3.2.

I will leave it up to the project maintainers as to when this issue should be closed. I don't know what change fixed this, and whether it is a change that will fix the problem in future versions as well (per initial comment, "...4.4.4 (correct) and 4.5.5 (incorrect) and 4.6.4 (correct)...").

conorbrandon added a commit to conorbrandon/ts-dynamodb that referenced this issue Dec 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

2 participants