Div using only bg-gradient class doesn't get its style applied on prod

1. Problem: Hey, so I just came across something strange, more details below.
2. Environment: Forked the Next.Js + Emotion example.
3. Link: https://codesandbox.io/s/silly-davinci-qbgj4?file=/pages/index.js:129-185

The style of a div using only gradient background class worked fine on dev, but not on prod. And when adding another class (text-white here), then it works:

• Working on dev, working on prod: <div tw="bg-gradient-to-b from-red-500 to-gray-400">
• Working on dev, not working on prod <div tw="bg-gradient-to-b from-red-500 to-gray-400 text-white">

If you want to try, go the the sandbox link above. I found a way to test on dev and on prod, by changing the dev command in the package.json. When you first launch, the dev command will be set on next dev. If you want to see the issue, change the dev command to next build && next start:

• Ex 1: next dev

• Ex 2: next build && next start

Does anyone have any idea why?

[Dramloc]

Hey @ben-rogerson,

The default emotion approach fixes this issue but after testing it on a larger example, I had some problems with it. Utilities like space-* and divide-* use the CSS sibling combinator (e.g.: :not([hidden])~:not([hidden])) and can cause layout shifts with this approach.

While testing this, I also found that some issues still remain with the advanced approach. Emotion seems to sometime create invalid CSS when serializing the style with stylis (see https://github.com/thysultan/stylis.js/issues/250). This issue can happen when the last declaration of a style is a CSS variable.

For example, in this snippet:

<span tw="ring-inset" />
<div tw="p-4" />

The ring-inset utility will be applied but the next CSS declaration (p-4) will be skipped by the browser.

In practice, this can cause a FOUC but it’s less frequent and less noticeable than the layout shifts of the default approach. I think you can keep the twin starter as it is and wait for the bug fix on stylis.

[Dramloc]

Hi,

You can find more information on this topic in the emotion docs: https://emotion.sh/docs/ssr.

I would suggest using the default approach if your project does not require the advanced approach. It provides better performance (with response streaming) and is easier to maintain. Also, most of its limitations can be worked around.

In the first approach, @emotion/react will create the CacheProvider under the hood and use it in every Emotion component, so it should have no impact on your application.