Generics in conditionals have differing behavior in 4.8

I found a break in zustand from looking at the logs of a failed NewErrors run. It might be more correct, but figured it was worth noting.

export type Store<T extends object> = {
    setState: (x: T) => void
    getState: () => T;
}

type ExtractState<S> = S extends { getState: () => infer T } ? T : never

type Extractable<S extends Store<object>> = {
    getServerState?: () => ExtractState<S>
}

export function f<TState extends object>(api: Extractable<Store<TState>>) {
//                                                        ~~~~~~~~~~~~~
// Type 'Store<TState>' does not satisfy the constraint 'Store<object>'.
//   Types of property 'setState' are incompatible.
//     Type '(x: TState) => void' is not assignable to type '(x: object) => void'.
//       Types of parameters 'x' and 'x' are incompatible.
//         Type 'object' is not assignable to type 'TState'.
//           'object' is assignable to the constraint of type 'TState', but 'TState' could be instantiated with a different subtype of constraint 'object'.
}

https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/src/react.ts#L30

export function useStore<TState extends State, StateSlice>(
  api: WithReact<StoreApi<TState>>,
//               ~~~~~~~~~~~~~~~~
// error TS2344: Type 'StoreApi<TState>' does not satisfy the constraint 'StoreApi<object>'.

There’s a few of these.

New errors for non-composite project https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tsconfig.json

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/src/react.ts#L30

  error TS2344: Type 'StoreApi<TState>' does not satisfy the constraint 'StoreApi<object>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/src/react.ts#L56

  error TS2344: Type 'Mutate<StoreApi<T>, Mos>' does not satisfy the constraint 'WithReact<StoreApi<object>>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/src/react.ts#L59

  error TS2344: Type 'Mutate<StoreApi<T>, Mos>' does not satisfy the constraint 'WithReact<StoreApi<object>>'.
  

• TS2345 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/src/react.ts#L68

  error TS2345: Argument of type 'StoreApi<T>' is not assignable to parameter of type 'WithReact<StoreApi<object>>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/context.test.tsx#L24

  error TS2344: Type 'StoreApi<CounterState>' does not satisfy the constraint 'StoreApi<object>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/context.test.tsx#L48

  error TS2344: Type 'StoreApi<CounterState>' does not satisfy the constraint 'StoreApi<object>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/context.test.tsx#L135

  error TS2344: Type 'StoreApi<CounterState>' does not satisfy the constraint 'StoreApi<object>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/context.test.tsx#L150

  error TS2344: Type 'StoreApi<CounterState>' does not satisfy the constraint 'StoreApi<object>'.
  

• TS2322 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/middlewareTypes.test.tsx#L171

  error TS2322: Type 'StoreApi<Omit<{ count: number; }, never>>' is not assignable to type 'StoreApi<object>'.
  

• TS2344 at https://github.com/pmndrs/zustand/blob/197e5d41993b0e3ad6ebef9a7e6a9161753072f1/tests/types.test.tsx#L86

  error TS2344: Type 'StoreApi<ExampleState>' does not satisfy the constraint 'WithReact<StoreApi<object>>'.
  

_Originally posted by @DanielRosenwasser in https://github.com/microsoft/TypeScript/issues/49488#issuecomment-1152817431_

[Andarist]

This is quite complex and beyond my understanding. We can already observe the issue with type here. However, the same behavior can be observed on 4.7 with this and if we change type to an interface then we might see an error on the variance annotation, see here.

In Zustand repo I couldn’t see the same annotation error though so I kept digging… and I’ve somewhat narrowed it down to this. In here we won’t observe the variance annotation error but it’s quite easy to get it - by removing some seamingly unrelated lines of code.

The code here has some cycles and stuff and I think that this just makes variance measurement to give up and thus it ends up too forgiving. For some reason though the type-based variant was accepted in the past and now it isn’t. It looks a little bit like as if variance computation became slightly smarter now and errors sooner rather than reporting unmeasurable (or similar)

Note that I’m just guessing a lot here.

[devanshj]

Hm, not sure how I made that slip-up, and I’m honestly a little confused about the interface/type alias difference. If you have some time to get a minimal repro that’d be at the very least useful for us to investigate.

Yeah I too am not sure what’s up with the interface vs type alias thing. Will try to get a minimal repro if I find time for it.