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

styled-components broken by #41841 #41886

Closed
sandersn opened this issue Dec 9, 2020 · 4 comments
Closed

styled-components broken by #41841 #41886

sandersn opened this issue Dec 9, 2020 · 4 comments
Assignees
Labels
Breaking Change Would introduce errors in existing code Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@sandersn
Copy link
Member

sandersn commented Dec 9, 2020

Found by overnight DT run for #41841

Here's a standalone repro; it's not minimal but it doesn't depend on anything else.

interface FunctionComponent<P = {}> {
    defaultProps?: Partial<P>;
}
type ComponentType<P = {}> = FunctionComponent<P>;
export type KProps<C extends string | ComponentType<any>> =
    object extends object ? Omit<C, any> & Partial<C> : never;
export interface StyledK<C extends string | ComponentType<any>> {
    (props: KProps<C>): never
}
type Constraint<T extends ComponentType> = T ;
export type StyledComponentInnerComponent<C> = C extends StyledK<infer I> ? I : C;
export type SProblem<C extends ComponentType<any>> = C extends StyledK<any> ? Constraint<StyledComponentInnerComponent<C>> : number;

Expected behavior:
No error, as in 4.1.

Actual behavior:
Error in SProblem on Constraint<StyledComponentInnerComponent<C>>:

error TS2344: Type 'StyledComponentInnerComponent<C>' does not satisfy the constraint 'ComponentType<{}>'.
  Type 'string | ComponentType<any> | C' is not assignable to type 'FunctionComponent<{}>'.
    Type 'string' has no properties in common with type 'FunctionComponent<{}>'.
      Type 'string | ComponentType<any>' is not assignable to type 'FunctionComponent<{}>'.
        Type 'string' has no properties in common with type 'FunctionComponent<{}>'.
@sandersn sandersn changed the title styled-components broken by https://github.com/microsoft/TypeScript/pull/41841 styled-components broken by #41841 Dec 9, 2020
@sandersn sandersn added the Bug A bug in TypeScript label Dec 9, 2020
@sandersn sandersn added this to the TypeScript 4.2.0 milestone Dec 9, 2020
@sandersn
Copy link
Member Author

sandersn commented Dec 9, 2020

Here's a smaller repo. I think it better illustrates the problem:

interface StyledK<C extends string> {
    (props: {}): never
}
type Constraint<T extends { p }> = T ;
type Inner<C> = C extends StyledK<infer I> ? I : C;
export type SProblem<C extends { p }> = C extends StyledK<any> ? Constraint<Inner<C>> : number;

I guess before the string constraint on C from the outer C extends StyledK<any> ? ... got dropped? It kind of looks like this new error is correct.

@ahejlsberg
Copy link
Member

I guess before the string constraint on C from the outer C extends StyledK ? ... got dropped? It kind of looks like this new error is correct.

Yes, that was the problem with not preserving substitution types in conditional types--constraints implied by outer conditional types were dropped. They're now preserved, which in this case reveals an error. If C is a StyledK<any> then Inner<C> is constrained to string | C, and string is not assignable to { p: any }.

BTW, I have no earthly idea what these types are supposed to be doing!

@sandersn
Copy link
Member Author

sandersn commented Dec 9, 2020

Presumably they made sense in situ. The standalone repro chops them up pretty badly. I'll go back to the original and try to figure out a workaround.

(There are nearby comments in the original along the lines of "I'm quitting now before my head starts hurting again." So.)

@ahejlsberg ahejlsberg added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Bug A bug in TypeScript labels Dec 9, 2020
@DanielRosenwasser DanielRosenwasser added the Breaking Change Would introduce errors in existing code label Dec 9, 2020
@sandersn
Copy link
Member Author

sandersn commented Dec 9, 2020

Later: It seems like the string constraint was a low-fi keyof JSX.IntrinsicElements substitute, because switching to that now compiles successfully. I'm afraid that it's going to be a lot slower though.

DefinitelyTyped/DefinitelyTyped#50046

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Would introduce errors in existing code Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants