Can the Design System team please, pretty pretty please, come to their senses?

@stephenmok @DanielDelCore

This is a genuine cry for help, because I don’t know how to make it clear anymore that you are making the lives of Marketplace Partners genuinely miserable. I know you’re all doing this with good intentions and everything, but you’re disregarding industry best practices left & right and it is becoming unbearable.

Case in point this time around: a new package was introduced @atlaskit/platform-feature-flags which was added to the @atlaskit/popper package as a production dependency. The @atlaskit/platform-feature-flags has a post install script which says yarn generate, implying that the platform that is building needs to use Yarn. In addition, the yarn generate script calls ts-node directly without having ts-node as a dependency on the project. The script is used to generate typings.

You are breaking 4 industry best practices here:

  1. Type generation should either be done prior to publishing the package, meaning @atlaskit/platform-feature-flags should have run it on prebuild, or it should be part of a devDependency as typings are only required during development.

  2. Do not assume globally installed packages and add them to your dependency list (ts-node)

  3. if you’re going to use a binary, you should not call it directly (ts-node) but at least use npx ts-node or yarn run ts-node.

  4. you should not enforce a build tool. If any such tool is required, you should stick with npm as this is the default package manager shipped with node

Seriously, get your sh*t together.

UPDATE 1/17: ok, so there is now a new version available that uses npm run, but as shown by the comment made by @aovsyannikov, you are still breaking an industry best practice by assuming a *nix based file system (usage of ./ and a shell script, which is not natively supported on windows)

Also, you have removed the ts-node reference, but replaced it with tsc without npx or yarn run in front of it, nor have typescript listed as a dependency, meaning that you expect the Typescript compiler to be installed available locally.


I get the following error message even when yarn and ts-node is installed (we switched from yarn to pnpm due to better mono repo support)

│ import fs from 'fs/promises';
│ ^^^^^^
│ SyntaxError: Cannot use import statement outside a module
│     at Object.compileFunction (node:vm:352:18)

as a workaround you can downgrade “@atlaskit/popper” to “5.4.2” passing this dependency right into package.json (in our case this is only indirect dependency for media-core )


Thanks for raising a flag regarding this. I am currently building a new connect app and just started building the UI. I kept hitting this issue and was puzzled why yarn would be needed at all. I was originally impressed with the level of documentation of the design system, but the more I am using it, the more I am worried about depending on it too much. My first red flag was the peer dependency on react 16, and now this. Since I am early in my journey, I am weighing the tradeoffs between building around atlaskit vs rolling my own components. Any thoughts would be really appreciated on this.


Although there are many vendors that have decided to either create their own components (some even recreated ADG3 in VueJS) or use AUI for cloud (yes, you can still use that, and it is actively maintained), there are also a lot of vendors that are using AtlasKit despite all its shortcomings. We’re also heavily invested in AtlasKit and have decided to continue down that path regardless of whatever curveball the Atlassian Design System team throws at us. In the end, we always find a workaround. My posts are mostly just to keep Atlassian to a higher standard. They’ve set the bar very high themselves years ago and I’m going to hold them accountable as long as I’m active in this community.

However, that should not distract you from building your apps. You should choose the path you feel most comfortable with, whether that is with custom components, AUI or just ranting about AtlasKit. As long as you don’t expect anything from the DS team, you’ll never get disappointed.


Hey @remie, :wave:t2:
Thank you for the feedback. That is a frustrating experience and we understand we missed the mark here. We’ve identified the responsible team and routed the feedback to them. We’ll get more specifics about the change and their current roadmap when they are back online early next week.

@lkaplan thank you for your considerate response. Please note that although I appreciate your effort, the underlying issue here is that Atlassian as a company has a history of missed marks with regard to publicly published artefacts, either with regard to outdated dependencies, incorrect dependencies, dependencies that proved to be malware and now dependencies that are not suitable for distribution.

That underlying problem of bad stewardship over a component suite on which a 1.5 billion dollar industry depends on is what needs to be addressed by Atlassian as a company. Not this specific issue at hand, by this specific team.


Hi there,
I get the following error message and cannot build my app

npm ERR! > @atlaskit/platform-feature-flags@0.0.9 generate
npm ERR! > ./scripts/
npm ERR! '.' is not recognized as an internal or external command,
npm ERR! operable program or batch file.

My environment is windows 11

Didn’t you know that Atlassian only considers those using either MacOS or any flavour of Linux as real developers?

1 Like

@stephenmok @DanielDelCore, so there is a new version of @atlaskit/platform-feature-flags (version 0.0.9, published yesterday), which addresses the use of yarn by replacing it with npm run and which removed ts-node

…but is still generating types on post install, replacing the requirement to have ts-node globally installed with the requirement to have tsc globally installed (without npx or yarn run prefix) and still relying on *nix type OS by having ./ file reference and shell scripts.

I hope this is a temporary workaround for a situation in which the typings are actually generated during build prior to publishing them to NPM?

Atlaskit versioning and dependency management are below grade. I believe each package is developed by a different team and they don’t synchronize at all. You end up blowing up your app with duplicated versions of the same Atlaskit packages and a lot of other dependencies that you don’t really need. I already raised this point in the past: [ACJIRA-2538] Better version management for Atlaskit components - Ecosystem Jira ( Atlassian acknowledges it is a problem, but nothing is done.

We cannot avoid using Atlaskit because we need the rich text viewer/editor. But it is sometimes very frustrating.

I wonder if a regular developer working on Atlaskit gets any training about npm packages, dependencies, and version management.

Thanks again for raising this feedback @remie + other folks here!

I’ve been in touch with the appropriate team for this one. They’ve seen your feedback and have been investigating. As you’ve noticed with the new version, it’s actively being worked on. They’ll be sharing more details soon.

(@DanielDelCore and I are not directly involved in this, hence why it’ll be our colleagues looking after feature flags who will update you here. @atlaskit includes packages beyond just the Atlassian Design System, from many front-end teams who work together across Atlassian.)

Yes, the Atlassian Marketplace Partners are painfully aware of this. We also do not know how to contact these teams as it is not mentioned anywhere in the documentation. The only thing we have to identify teams is this part:

"atlassian": {
    "team": "UIP: Cycle Time Flex",
    "inPublicMirror": true,
    "releaseModel": "continuous"

But that is non-descriptive to us.

To be honest, this is exactly what I mean when I refer to bad stewardship in this post. There is no overarching body to control the quality of what is published to NPM.

Anyway, the reason I contacted you and @DanielDelCore is because even if this specific package is created by another team, it is a transitive dependency for @atlaskit/popper on which many DS packages (tooltip, datetime-picker, popup, inline-dialog) rely. I did not get this dependency by manually including some obscure @atlaskit package. I got it from DS team managed components.

Perhaps the DS team should be more strict in terms of dependency management and use specific versions instead of version ranges, as apparently you cannot rely on your own colleagues to not break your packages :person_shrugging:

1 Like

Hi there,
we are also experiencing problems with our build and we are using the @atlaskit/dropdown-menu which of course has a dependency on @atlaskit/platform-feature-flags.
Can someone think of developers working on windows too? (Colleagues that are working on mac are not affected)

Is there any workaround for this right now or do we have to wait for a new release of the library?

1 Like

@remie You speak from my soul! :smiley:
I mean Atlaskit is out since 4 years and it still feels like a patchwork library developed by some students…
I would really love to see Atlassian putting some efforts and love into the widely used industry standards instead of just pushing stuff like the Forge UI-Kit, which is kind of cool for really simple use-cases but not for the majority of partners who need some development flexibility.
Microsoft learned that too a few years ago… :wink:

1 Like

Hi folks, a new version of @atlaskit/platform-feature-flags was shipped on January 20th that removes the postinstall script call.

Thank you Remie and everyone here for taking the time to raise the issues around how we have been handling dependencies and version management for components. We made a mistake here and are sorry for the disruption it has caused. We are committed to learning from this and doing better.

We recognise the need for better controls to prevent these disruptions from happening again, and we are making this a priority on behalf of our developer community to improve the productivity of Marketplace Partners and the broader developer ecosystem. We know that Atlaskit is especially important as it impacts developers across all of our cloud platforms.

The context as to why this new feature flag package was introduced: We’re working towards improving the time it takes for fixes and new features to reach Atlaskit. The introduction of feature flags to our dev pipeline was done to enable Atlassian teams to rollout these changes with more control and higher quality.

Thank you for your ongoing support and engagement, and if you have questions, please ask us right here in CDAC.