This behavior was introduced by microsoft/TypeScript#57122 and released with TypeScript 5.4. I filed microsoft/TypeScript#57744. It's considered a regression (so essentially a bug) and it has been fixed in microsoft/TypeScript#57801, which should be released with TypeScript 5.5.

In the meantime, the suggested workaround from that issue is to refactor to an inner utility type that doesn't have the any[] requirement:

type _Hmm<T> = T extends number[] ? 
  MustBeArray<{ [I in keyof T]: 1 }> : never // okay

type Hmm<T extends any[]> = _Hmm<T> // okay

type Z = Hmm<[2, 3, 4]>
//   ^? type Z = [1, 1, 1]

Playground link to code

First of all, you could make a new branch in your source control repo (if you have one) and start the migration.

Then, an easy way to check if your codebase works in TypeScript 4.8 is simply to install that version, run tsc on your code.

Also, there's a list of breaking changes on the TypeScript repo. You could go through those.

I'm not aware of any tools that could do this for you. However, if your project doesn't have any really complicated types, then it shouldn't be that hard to do all this manually.

It's very difficult to say exactly why your code worked before, stopped working, and then apparently works again in the nightly version of TypeScript. I mean, it's relatively straightforward to give a rundown of the "what" but not the "how":

• Your code broke with microsoft/TypeScript#55140, a bug fix for microsoft/TypeScript#55129, an issue with mapped types. This was released with TypeScript 5.4.

• Your code was fixed with microsoft/TypeScript#55371, a bug fix for microsoft/TypeScript#55364, an issue with template literal types. This will be released with TypeScript 5.5.

These issues don't have anything obvious to do with each other. Your code does involve mapped types and template literal types, so it's quite possible that the break and the fix are touching different pieces of your code and it's essentially a coincidence.

If you need to know what's going on you might try to come up with a more minimal example, and/or file your own GitHub issue about it. Until and unless that happens I don't have any further insight.

On the other hand, a general approach for situations in which you are sure that a type X is assignable to a type Y but the compiler can't see it (generally because one or both types depend on generic types, and the compiler doesn't have much ability to do higher-order generic reasoning), you can often use the [intersection(https://www.typescriptlang.org/docs/handbook/2/objects.html#intersection-types) X & Y instead of X. If you're correct about the assignability, then ultimately X & Y will be equivalent (more or less) to X. And the compiler will always recognize X & Y is assignable to X, by definition of the intersection.

So, in your example, you could always do something like

declare function createEnahncer<T extends any[]>(composition: T) {
  const mapSelectorToValueNames = <K extends SelectorKeysCollection<T>>(
      name: K
  ): (keyof SelectorValuesCollection<T>) & ExtractSelectorPropertyName<K>;

to avoid the error. If you're using complicated types (especially things like UnionToIntersection) then you will probably eventually need something like this, even if the particular issue in your question turns out to be a real bug.

Playground link to code