I need to upgrade to styled-components v4 because new packages added to my project use it (i.e. reactour).
I am getting the following build warnings and there a multiple UI errors when running with v4:
npm WARN @atlaskit/calendar@9.2.10 requires a peer of styled-components@^3.2.6 but none is installed. You must install peer dependencies yourself.
Similar warnings for:: @atlaskit/icon@20.1.2, @atlaskit/theme@10.0.4, etc…
Is there a workaround for this?
Any advice would be helpful.
I updated all my components to the latest versions and have the following 2 errors so far:
Note, component @atlaskit/dropdown-menu uses component @atlaskit/droplist which is being deprecated
Console message:
The “innerRef” API has been removed in styled-components v4 in favor of React 16 ref forwarding, use “ref” instead like a typical component. “innerRef” was detected on component “Droplist__Trigger”
As a work around I changed Droplist.js (in node modules) replacing (2 instances) innerRef with ref.
I would like to see the package updated with similar change.
Console message:
StyleSheetManager.js:31 The “innerRef” API has been removed in styled-components v4 in favor of React 16 ref forwarding, use “ref” instead like a typical component. “innerRef” was detected on component “styled.div”.
I am aware these packages will switch over to emotion, but in the meantime can atlaskit update the packages for these 2 items.
I would greatly appreciate this or any advice would be helpful.
Hi @EdwardL, are you able to try using styled-components v5?
Hi @MattCharlton, no I did not try v5.
Since we had to deliver the software quickly, I ended up using another package @reach/menu-button for the non-working UI components.
I will try your suggestion in the future.
Thanks
Hi @MattCharlton,
It failed my test for @atlaskit/inline-dialog 13.0.8, with styled-components v5.2.1 and Chrome v86.
The dialog is still positioned in the upper left hand corner.
I believe the other dependencies being used are up to date.
typescript 4.0.5
@atlaskit/select 13.0.6
@atlaskit/button 15.1.1
@atlaskit/analytics-next 8.0.2
@atlaskit/popper 5.0.3
@atlaskit/theme 11.0.1
react-node-resolver 2.0.1
tslib 2.0.3
I’ll test again with a future version.
@EdwardL Ah that sucks. I wasn’t sure if the latest version had backwards compatibility with innerRef. It clearly does not. We are stuck on v3 of styled-components for the foreseeable future i’m afraid.
Hi @MattCharlton,
We are also unable to use atlaskit/dropdown-menu with v4 of styled-component.
Code sandbox (clicking on the items doesn’t generate an onClick event that log to the console) :
Knowing styled-components v4 was released 2 years ago, I don’t understand why there are still incompatibilities as this is blocking the users to patch other libraries. Or, as mentioned by Edward, we have to move away from Atlaskit (which we obviously do, for security reasons).
Kind regards,
Edwin Rozie
Hi @Edwin,
it’s tracked here: Log in with Atlassian account
I don’t see valid security reasons which prevent you from staying on styled-components v3. The only known advisory is (afaik) The `size` option isn't honored after following a redirect in node-fetch · CVE-2020-15168 · GitHub Advisory Database · GitHub, which most likely has little or no impact.
I do agree that upgrading / replacing styled-components is a big blocker for all app vendors. Unfortunately, this is definitely not a top priority of Atlassian. Though, things are currently moving a bit e.g., Webpack 5 support due to Atlassian’s teams being blocked. So hopefully this issue is resolved sooner than later.
I know of a few vendors who are migrating or no longer use Atlaskit. The situation throughout last year in which not all sources were available to build Atlaskit, and in my opinion the current solution with the atlassian-frontend-mirror, were blocking and costing (time and monetary) vendors big time.
I can only give two advice:
Hi @dennis.fischer ,
Thank you for the link and info.
The security risk is indeed not that styled-components v3 is insecure on its own. The problem is that other libraries are requiring v4 to be used for their latest feature and security updates. So not able to upgrade to v4 would cause a risk for the other libraries that we cannot update any more.
It is indeed not my ambition to build another replacement for Atlaskit. I would simply expect Atlassian to keep this up to date (using other libraries breaks the look & feel for the user). Compare it with Google: they also take a 30% margin on the Android marketplace, but they keep their SDK (including front-end) up to date and - to my understanding - in sync with the community.
I think we should express our expectations clearly towards Atlassian to keep their SDK and UI libraries up to date and in sync with the markeplace partner community.
With kind regards,
Edwin Rozie
I applaud your enthousiasme @Edwin. Let me know if you managed to get any traction on this. I tried (Community request: can we have a no-bullshit update on the future AtlasKit?) which resulted in the first & only post to reach over 100 likes on this forum but to no avail.
Actually, I really would like to hear what @mhart / @hari think about the fact that Marketplace Partners are required to resolve all known vulnerabilities in packages in a timely fashion, but can’t because of an dependency on an Atlassian provided (and encouraged) library?
Does that mean that we get a free pass if we are in violation of these terms because of AtlasKit, or does it mean that we should not use AtlasKit to ensure we are in compliance?
This is specifically interesting because the latter would mean that AtlasKit has become a radioactive disaster.
CC: @nmansilla
Hey @remie!
Inside of Atlassian we are consistently scanning these repositories for known vulnerabilities in third party packages. When they’re identified, we raise an internal vulnerability ticket for the team, and start the SLA for the team in line with our policy outlined here: Security Bugfix Policy | Atlassian.
Teams are generally good at adhering to these timeframes, but every once in a while something does go awry for whatever reason, and the timeframes get missed. In the events that does happen, we will obviously be flexible in how we address that dependency with people who are working with them downstream.
This specific scenario hasn’t been war-gamed out into a documented process for our team yet - but suffice to say that if we aren’t able to meet our SLA for whatever reason, then we’re obviously going to be reasonable about the flow on impact of that issue.
I hope that helps answer the question 
Cheers,
Matt
Appreciate the elaborate answer @mhart!
However, I can’t say the answer itself doesn’t give me pause, becase the Marketplace Partner security requirements for Cloud apps states that vendors are not allowed to use upstream sources with known vulnerabilities and that they should refactor / implement other solutions if the upstream source does not fix the vulnerability within the timeframe of the SLA.
Do I understand the standing policy (based on the document & your answer) correctly that In any other instance, the excuse that the upstream party is not fixing the vulnerability in time is not acceptable, except if those packages are from Atlassian? And that the decision which package / vulnerability is acceptable is the sole discretion of Atlassian?
I’m also interested to learn how you factor in the dependency chain in your vulnerability scanning. Styled Components V3 itself might not have a severe known vulnerability, but as @Edwin pointed out, it prevents us to update other packages which may not be included in the AtlasKit project but are part of our Cloud apps. Doesn’t this create a blind spot? Shouldn’t the policy be extended to also state that you have to upgrade (or migrate away from it) to the latest & greatest within a year of a new version or package deprecation (i.e. request)?
Also, and maybe you can’t share this with us, but what are the real life consequences for Atlassian if you don’t meet your SLA’s? Because for vendors, Atlassian has been very outspoken: removal of the app after 90 days if we do not resolve any issue raised by Atlassian properly.
Apart from the gracious (albeit non-documented) leniency towards vendors for Atlassian own non-compliance, can we expect a more severe penalty instead of just acknowledging that you yield more power over vendors than over your own teams?
Hi @remie - thanks for the reply.
These are all great questions, and I’m going to be honest and say I don’t hold all the answers. What I do know is that we in Ecosystem Security try to be as reasonable as possible, and ultimately want to work together to ensure the security of our joint customers.
In cases where Atlassian is the cause of a security related issue, we are more than happy to work together to get the issue resolved - and for pretty much all of the cases we’ve been involved in, open communication between vendors and the Ecosystem Security team has resulted in an agreeable outcome on both sides.
It’s not in either of our best interests for us to get to a stage where we need to consider removing apps from the marketplace, we don’t want to do it, and don’t take that action lightly.
The only times where we’ve been forced to review an apps distribution status in the Atlassian Marketplace is when there have been (particularly nasty) vulnerabilities within apps, and the vendor has gone completely off the grid and - despite our best efforts - we were unable to make contact with the vendor.
As I said - we’re still hard at work putting all of the pieces of the puzzle together to help increase the security of our ecosystem, and so I don’t currently have all the answers - but as long as there has been an open dialog, we haven’t had any issues so far in coming to reasonable solutions to any problem that we have faced with our vendor community (and so thank you all for your ongoing outreach and feedback).
Generally, if you need guidance on specific packages, or specific issues you’re facing, the best way to get that guidance is by creating an ESSD ticket here.
Thanks,
Matt