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

Emotion 10 + Emotion 11 side-by-side problems #1974

Closed
RoystonS opened this issue Aug 17, 2020 · 6 comments
Closed

Emotion 10 + Emotion 11 side-by-side problems #1974

RoystonS opened this issue Aug 17, 2020 · 6 comments
Labels

Comments

@RoystonS
Copy link
Contributor

Current behavior:

I'm currently attempting an upgrade of our codebase to Emotion 11 and it's proving extremely problematic as we have a variety of things that still require Emotion 10. (e.g. storybook). So I have a node_modules folder that contains both Emotion 10 and Emotion 11.

There are some TypeScript issues (specifically the dreaded TS2742 error) which I won't list here but the most significant problem I'm having right now is with the versioning of the @emotion/serialize package: the Emotion 10 version of this package has a higher version number than the Emotion 11 version and so is picked up by @emotion/react of Emotion 11.

To reproduce:

  1. Create a lerna repo and install storybook at the top level. That uses Emotion 10
  2. Create a subpackage that uses Emotion 11's @emotion/react package.
  3. Try to use the Emotion 11 package; it won't work because it picks up @emotion/serialize@0.11.16 from Emotion 10, used by storybook.

The problem is that @emotion/react@11.0.0-next.14 has a dependency on ^0.11.15-next.2. That dependency will be satisfied by @emotion/serialize@0.11.16

Expected behavior:

If Emotion 11 packages require other Emotion 11 packages, they should be picking them up, not accidentally picking up Emotion 10 packages.

@Andarist
Copy link
Member

Sorry to hear that - we automate our releases and versioning using Changesets. When maintaining 2 separate release lines - which both depend on a shared versioning scheme - things get sometimes tricky and some errors, like this, are easy to miss as this situation is not automatically validated. This is especially troublesome when dealing with 0.x packages. Not sure how to best handle this on the Changesets level, but I will keep thinking about this.

The good news is that the fix is quite simple - we should just bump @emotion/serialize to the next major version on the next and this is already happening. The next release will fix this: #1963 . I will go through pending PRs tomorrow to see if there is anything that could be handled quickly and I'm going to merge this PR which should trigger a release that is going to fix this.

@RoystonS
Copy link
Contributor Author

Thanks so much for the fast response! I've managed a bit of a temporary workaround using yarn's resolutions system in case others are stuck on this:

"resolutions": {
    "@storybook/*/**/@emotion/serialize": "0.11.16",
    "**/@emotion/serialize": "0.11.15-next.2"
}

but it's only a temporary workaround: we automatically run yarn-deduplicate at Git commit time to detect where we have accidentally pulled down multiple versions of packages, and it's flagging up that the dependencies that are getting 0.11.15-next.2 'should' be being given 0.11.16 instead because it's compatible. We can suspend that for a little bit.

@Andarist
Copy link
Member

I've released new next versions - this should resolve your issue so I'm going to close this right now. I would love to hear if this has fixed the situation for you though, so free to just answer back here - I will make sure to get back to you if needed.

@RoystonS
Copy link
Contributor Author

Yep, @Andarist I've successfully pulled in the updated packages and that's somewhat cleaner enabling me to discover the next hurdle where attributes that were previously filtered by Emotion v10 don't seem to be in v11. Will investigate and raise separate issue.

@levymetal
Copy link

I'm getting a similar issue with a project that uses Emotion 11 and Storybook 6 (which uses Emotion 10). @emotion/sheet@0.9.4 from @storybook#theming#@emotion#core#@emotion#cache gets hoisted to @emotion/sheet, and Emotion 11 pulls that instead of @emotion/sheet@^1.0.3 throwing a TypeError: cache.sheet.hydrate is not a function. Manually adding @emotion/sheet@^1.0.3 to the package hoists it to @emotion/sheet.

This only happens with yarn and not npm. However, I don't understand why Emotion 11 breaks with this hoisting strategy;
I don't understand why it's pulling sheet from the root instead of its own deps. The node_modules dir in @emotion/react contains the correct version of sheet.

I've created a repro here: https://github.com/levymetal/emotion-11-conflict-repro. Running yarn start throws the TypeError above. Removing @storybook/react or adding @emotion/sheet@^1.0.3 fixes the issue.

@Andarist
Copy link
Member

Andarist commented Nov 8, 2021

I've given the answer to @levymetal's issue here: storybookjs/storybook#13300 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants