Remove @emotion/styled from components

[atanasster]

• remove @emotion/styled in favor of @emotion/react's css prop - working this PR with @lachlanjc.

a few questions we can discuss

• the new mergeProps function is merging "arrays" vs "objects" - this can be used for overwriting css props when they are not supported by a browser - ie multiple sx props with the same name (we will need to modify the internal css from '@theme-ui/css' to return an array of props)
• do we need to use the jsx pragma still for the emotion css prop
• any performance/bundle size measurements

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/systemui/theme-ui/jeojhf9md
✅ Preview: https://theme-ui-git-fork-atanasster-remove-emotion-styled.systemui.vercel.app

[Deployment for 021546b canceled]

[lachlanjc]

Thanks so much for submitting this :)

[lachlanjc]

Quick aside—we’re also depending on @emotion/styled in the mdx package, to power the Themed component. So it will still be bundled inside theme-ui until we replace that as well, though I think that should be a separate PR.

[lachlanjc]

I just tried running size-limit on the uncompressed, built versions of the current release vs this branch, & it reduces size by 1KB in this package (17.44KB vs 16.55KB). Less than I thought/hoped, but it’s a solid step nonetheless, & once we remove @emotion/styled from mdx as well, that’s a much larger reduction (that package alone is 5% of our current bundle size, plus its dependencies).

[hasparus]

index.d.ts imports StyledComponent and we leak it in our public API.

import { StyledComponent } from '@emotion/styled'

export const Box: StyledComponent<BoxOwnProps, BoxProps>

We'll need an update to index.d.ts here.

[atanasster]

I can update it for the sake of it, however it is imported by @emotion/react as a devDependency anyway:

https://github.com/emotion-js/emotion/blob/a89d4257b0246a1640a99f77838e5edad4ec4386/packages/react/package.json#L54

[hasparus]

as a devDependency anyway

It's not installed in user's node_modules then.

[atanasster]

Not sure what to do about it - all types are dev dependencies and they are not part of the production bundles.

1. We can add the type and pretty much duplicate StyledComponent, with all the risks duplicating code entails.
2. We can add @emotion/styled as a devDependency (different from using it at run-time as previously).
3. We can leave as is.

I took #3 but open to different opinions.

[hasparus]

We can add @emotion/styled as a devDependency (different from using it at run-time as previously).
Not sure what to do about it - all types are dev dependencies and they are not part of the production bundles.

"dependencies" and "devDependencies" have no inherent meaning in the context of bundling. If I remember correctly, brunch bundler used to bundle all "dependencies", but webpack doesn't care about them at all (It traverses your module tree.)

They have meaning for package managers however. If a package A has package B in "dependencies", both will appear in user's node_modules when they do npm install A. This is not the case for "devDependencies". In case of "peerDependencies", the user will get a warning in the terminal prompting them to install the peerDependency.

If we use types from a devDependency, users won't know to install the package, but the types will collapse to any or fail their build when their tsconfig option skipLibCheck is set to false.

You can read more about it in npm docs:

• dependencies
• devDependencies
• peerDependencies

There are also bundledDependencies and optionalDependencies, but I haven't seen anybody use them, so I'm not sure what's the support like.

[lachlanjc]

What part of the type do we need from Emotion?

[atanasster]

Its just ‘StyledComponent’

theme-ui/packages/components/index.d.ts

Line 2 in 90b7c10

import { StyledComponent } from '@emotion/styled'

[hasparus]

Thanks for the review, I think it should be a devDependency.

So if somebody is depending just on theme-ui, and doesn't have @emotion/styled in their own dependencies or devDependencies, this change will remove @emotion/styled from their node_modules.

If they use TypeScript with skipLibCheck: false, we'll crash their build.
If they use JavaScript or skip lib check, we'll de facto disable editor support on Box and Flex, what is still an regression.

If we remove @emotion/styled from runtime, we need to stop depending on their types, especially since the types for Box and Flex is this PR are now incorrect.

[lachlanjc]

@hasparus Will your PR to move @emotion/styled to user/peer deps fix this?

[hasparus]

@lachlanjc I started working on removing @emotion/styled on remove-emotion-styled-2 branch — take a look at develop...remove-emotion-styled-2.

I think we'll release peer-deps branch and @emotion/styled removal in the same version — both might be breaking changes.

[lachlanjc]

Closing in favor of #2043!