-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Typescript issue with CSSObject in version 11.11.5 of @emotion/styled #3174
Comments
As a workaround, you can use TypeScript, currently, caches some types resolved while trying to match against the first overload. This is a long-standing issue and there is a recent-ish fix for this open here. You can even quickly verify that it does indeed fix this issue since there is a TS playground with that build available: TS playground |
Thanks for rapid action on this! 🙏 Can confirm that |
Yeah, maybe - we have to investigate this further to determine which tradeoff is better and if we can do anything to mitigate the issue on our side without reverting the change that changed this. |
Alternatively make a release that indicates a breaking change and update documentation accordingly |
Thanks for notifying, looking into it. Looks really strange for now, to be honest, since I can't understand why this worked before if it's broken now.
Essentially, every attribute with the closed set of values (like |
Minimized example of the same error, in case someone wants to investigate too: interface Styles {
position?: 'left';
}
type StylesCreator = () => Styles;
interface Styled {
// (creator: StylesCreator): void // uncomment this to remove error
(styles: Styles): void
(creator: StylesCreator): void
}
declare const styled: Styled
styled(() => ({ position: 'left' })) // type `string` is not assignable to type `"left"` |
Yeah, I mentioned above that it's related to signature caching that happens when resolving the first overload. The fix would be to add a leading overload that would be capable of introducing proper contextual types for those creator functions |
This being a workaround is debatable when talking about projects with hundreds or thousands of rules containing the |
I created a package called emotion-styled-codemod if anyone is blocked by this, you can run it using npx: npx emotion-styled-codemod There's a transform that adds |
Current behavior:
Update @emotion/styled from 11.11.0 => 11.11.5
To reproduce:
We have several styled components in our project and we started to get TS errors on a lot of them after this update:
Example component that doesn't work:
Gives this error:
This is a breaking change.
Strangely it seems to depend on which css-attributes you are styling. This works for example:
There are several ways around this for example these variants seem to work:
or
Expected behavior:
There should be no breaking changes in patch versions (in this case TS errors)
Code like this should work since it returns a valid CSSObject:
Environment information:
react
version: 18.2.0@emotion/react
version: 11.11.4@emotion/styled
version: 11.11.5The text was updated successfully, but these errors were encountered: