Styled-components v3 dependency in Atlaskit is causing problems

I was using styled-components v4 with Atlaskit successfully so far, but unfortunately today I hit the wall when trying to use @atlaskit/flag.
You can see the problem here: peaceful-borg-2qy3p - CodeSandbox

Any ideas how to work around this issue?

I’ve noticed that there is a task for this. It says that styled-components will be replaced by another CSSinJS solution. Unfortunately there were no updates recently. @dmorrow can you help here? :slight_smile:

1 Like

Hi @Grzegorz.Tanczyk,

I’m not sure, but I’ve asked someone to help. Please let me know if you don’t receive a response.

Regards,
Dugald

2 Likes

Hi @Grzegorz.Tanczyk,

You are running into this issue because @atlaskit/flag has a peer-dependency on styled-components version 3.2.6. That version is not compatible v4.

We are currently working on a separate effort to improve the performance of @atlaskit/flag. As part of this effort, we are replacing the styled-components with Emotion (see below). This would remove the peer-dependency on the CSS-in-JS library that is used internally.
We expect this to take a couple of weeks based on our estimations. Once refactor is done, you’ll no longer have the issue.

For now though, you can get around this problem by using styled-components v3.2.6. I cloned your code-sandbox and downgraded the version of styled-components and everything works as expected. You can check it out here

As for Log in with Atlassian account – we are settling for Emotion for now, but we are exploring other options that might provide better performance. But we don’t have any concrete plans or timelines on when that would happen.

Hope that answers your question. Apologies for any inconvenience.

Regards,
Harsha

4 Likes

Thanks for the update, I will eagerly wait for improved version of atlaskit/flag. Meanwhile I need to use my own simplified implementation, because I can’t downgrade to styled components v3 for other reasons.

I forced @atlaskit/flag to use styled-components@5.* and (fingers crossed) it works.

But I am slowly removing @atlaskit/* components from my repo (for example by replacing @atlaskit/select with react-select)

My app running on both cloud and server and we are using @atlaskit component. we also face similar issue.

We also notice that it’s not happen on cloud but it’s frequently happen with server. in cloud app resource load inside iframe so conflict of style-component is less until and unless atlaskit component use different version of styled-components.

But in server - if any other vendor also use different version of styled-components there are changes to break UI of both app. this was generally happen on Dashboard pages. bcoz all UI resources load inside single html source and it create conflict.

atlaskit should get rid of peer-dependency on styled-components ASAP.

Thanks,
Umang

To be honest, although I fully agree with the assessment that AtlasKit should either upgrade or remove Styled Components, your assertion that this will fix resource conflicts between apps in Server is incorrect. I’ve encountered the same issue with other packages in the past, incl. conflicts with Atlassian Jira native resources (not even other vendors).

The only way to work around this is to A) implement the use of iframes yourself in Server, which we do for all UI integrations where possible, and B) try to prevent use of global namespace by bundling your apps.

Unfortunately, as we both discovered, Styled Components (and also React) natively bind to the global namespace even if you use a bundler. In your case, you could have used an iframe in your gadget. In our case, we are limited by Atlassian because we need to detect if the user is on the Version, Release or Components page, and there are no page specifics contexts or entry points available in these pages. So our resources are loaded on every jira page (alt.general) only to detect whether it should do something.

One of the things we did do as a result of our both apps colliding is that we are now loading React & Styled Components asynchronously, and only if the user is on the Version, Release or Components page. That should limit the amount of collision points, although we still rely on the arrive package, which has caused a collision as well in the past.

Anyway, long story short: yes, Atlassian should do something about AtlasKit (see also Community request: can we have a no-bullshit update on the future AtlasKit? and Happy anniversary, great topic 🎉 RIP AtlasKit 🪦), but no, this will not solve the dependency collision on Server.

1 Like

Hi @umang.savaliya, most of the design-system components are already migrated to the Emotion CSS-in-JS library.

You can read more about the work progress here:

We’ve recently started pushing to convert the remaining components over to emotion. There are currently 25 components still depending on styled. 10 of those components are deprecated and will not be migrated, leaving us with 15 components still to go
[…]
We want to finish this by the end of Q1.

The “Q1” means the first quarter of the financial year that is the 3rd quarter of 2021.

If you want to quickly check if the given NPM package is using either styled-components or emotion you can run this command in the terminal:

$ npm info @atlaskit/flag  peerDependencies dependencies --json | grep -E "styled|emotion"
> "@emotion/core": "^10.0.9"

This will output the information about what CSS-in-JS library is used by the @atlaskit/flag package.

Best regards,
Maciej Adamczak
Atlassian Developer

PS: I’m not part of the Design System team that is working on those changes, so I can’t tell you more when the migration will be finished. I’m working in the DC teams, and we are also waiting for this work to be finished.

4 Likes

Thanks @madamczak for update.! it’s really good to hear about this migration. Eagerly waiting to complete this activity so will upgrade our app component.

1 Like