Mateusz Burzyński

I might fix this in the coming weeks by finally migrating to `development` condition in `package.json#exports`

Unfortunately, it is more complicated than that since there is also some other work that has to be done in preparation for that.

`@emotion/native` is mainly driven by external contributions. I don't really use Emotion in the context of React Native and I don't have tooling and other things set up to jump...

Could somebody familiar with the issue describe step by step how the leak is created here? I admittedly haven't looked into this code yet, a concise description of the problem...

Seeing the full setup would be really helpful. The fix would be to add `"worker"` to those conditions [here](https://github.com/emotion-js/emotion/blob/f3b268f7c52103979402da919c9c0dd3f9e0e189/packages/server/package.json#L83-L85) but then we'd also have to differentiate code paths somehow between...

The problem is that we dont want installations to trigger missing peer dep errors in package managers that are not aware of `peerDependenciesMeta`. In those this peer dep would be...

If this would be a different peer dep than `@types/react` I would also add it to `peerDependencies` despite it being optional. It feels to me though that `@types/react` are somewhat...

Are you using the app directory? Streaming? Are you able to provide a repro case?

It's not a fix - it's a workaround that makes using the `css` prop impossible. I can't say what a fix is since nobody has shared a repro case here

It's an interesting case! It might be a little bit tricky to fix (the no construct signatures thing) given the structure of our packages - but I didn't really analyze...