Although the Design Team is now actively maintaining a subset of the components, migrating them to emotion and keeping them up-to-date, it is completely unclear who is responsible for the other AtlasKit components. It is also unclear whether these components will be following the lead from the Design Team and will be migrated / upgraded anytime soon.
Many of these components are critical to the Atlassian Ecosystem, like the Editor. These are also components that are not likely to be deprecated given that they are also extensively used within the Atlassian products.
Would it be possible for Atlassian to
A) make it clear which team(s) are responsible for which component(s)?
B) share some sort of roadmap for upgrading the remaining AtlasKit components or mark them as deprecated?
While the editor has more or less responsible party, the JQL editor libraries is in a more weird and undecided state.
It hasn’t been updated since the initial publication, and there’s no public information regarding its future. And somehow it was released with dependency on old styled-components library (which has vulnerabilities in dependency tree and incompatible with newer react versions), which was removed by that moment from core Atlaskit libraries.
There is no mention of this anywhere right? You know probably because you have either interacted with the team or have other direct contacts within Atlassian. But for any other developer, it is completely unclear who to reach out to with regard to the state of these components.
For the other components and the editor, I have no idea. I’d really like some clarification on when the editor will be upgraded to React 17+ and drop the styled-components dependency.
I’m not across the details of AtlasKit and the direction the team would like to take it so I’ve raised awareness of this topic to the team. Hopefully you will get a response from the team.
A load of Atlaskit components seem to be tied to React 16.8 which is from February 2019 and Typescript 4.9.5 which is from Jan 2023.
We’d really like to be able to use newer versions of those dependencies without forcing our tools to let us and without having to do extra careful testing to make sure nothing is broken.
@jbevan just take @atlaskit/tokens, pick a React component library that you like and is decently supported and write your own theme that matches Atlaskit
We did this as an internal hackathon project as and experiment and it worked, it was actually super easy. I haven’t checked whether atlaskit’s license would allow it, nor whether my company would ever publish that, but it’s getting more and more tempting.
While I completely understand your ask to take this on holistically, there isn’t any team doing so. So I can only offer some practical advice to “give piece(-by-piece) a chance.” Specifically, I recommend raising component by component bugs for the things you need. In a way, it’s the converse of the OP ask:
Once you have issues, please feel free to promote here and drive some consensus about the most important priorities.
I fully realize this is less than ideal but I do see the design team making some regular, incremental progress on updating components; hence, I’m trying to give the community the best clues possible to activate our resources. I hope that compromise is practical, even if tedious.
If we know which teams are responsible for which components, it will become a lot easier to reach out to the right person to get help with fixes. Which brings us to the second part:
Can you please tell us where we should raise such issues? Because the DS team might have a bug tracker, but other teams don’t.
We build our own design system which includes all ADS tokens and add more to it. Also we are using atlaskit completely, but I plan to write a resolver to use React18 for our own components but React16 for atlaskit. It’s almost becoming necessary to go that way, because some new React libraries or newest versions are completely incompatible to React16. But for the moment, most things “just work”.
The main concern of Atlaskit should be to upgrade to newest Typescript and React versions. It’s simply not state of the art to use such an old base for UI libraries. Furthermore both UIkit 1/2 and Atlaskit should be in harmony with their dependency version requirements, but it seems to me they are completely out of sync in any way.
Sorry, I forgot to hyperlink in my response. Please use the standard bug reporting option in developer support. That way, putting the actual bug reports into the right tracker is our responsibility.
I’m personally committed to this idea. Shall we call it the “principle of explicit ownership”? It echos from this prior comment about how to organize CDAC:
Making this principle real is a long-term project and could not be enacted fast enough to help solve for the Atlaskit problems. It’s not simply a technical matter of gathering data.
