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:
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.
Do not assume globally installed packages and add them to your dependency list (ts-node)
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.
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.
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,
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/generate-types.sh
npm ERR! '.' is not recognized as an internal or external command,
npm ERR! operable program or batch file.
@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.net). 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:
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
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?
@remie You speak from my soul!
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…
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.
Since the inclusion of this “@atlaskit/platform-feature-flags” dependency in our projects we have this runtime error which is preventing any features from running:
The issue is that in the package code, they depend on an overwrite of process, but are not actually overriding it in their production build:
const ENV_ENABLE_PLATFORM_FF = // Use global "process" variable and process.env['FLAG_NAME'] syntax, so it can be replaced by webpack DefinePlugin
typeof process !== 'undefined' ? process.env['ENABLE_PLATFORM_FF'] === 'true' : false;
Given that you are shipping for the browser, your bundler probably does have a polyfill for process so that it works in the browser. That means that process will not be undefined, but it also does not have an env property. As they do not check for env because they always expect this property to exist (they are only checking on process being available), this will break in the browser.
As a workaround, I would instruct your bundler to replace process.env['ENABLE_PLATFORM_FF'].
@SonikaChaudhary you are shipping code that is not optimised for use in the browser.
Please either get someone to help you with creating actual usable shippable code, or get your team to step away from their computer. As I mentioned before, I don’t know how to make clear anymore that several teams within Atlassian have no business in shipping public code as they obviously have no experience whatsoever in creating production-ready packages without being rude. So forgive me for being rude, but you have to understand that it is unacceptable for a multi-billion dollar company fostering a multi-billion dollar Economy to ship code that has not had a review from a senior developer that actually know what they’re doing. You’re learning on the job at the expense of your ecosystem, and I truly, honestly, accuse Atlassian of wrongdoing to both you and your team for you to have to endure this.
CC @tpettersen, this is beneath Atlassian. Please make sure the appropriate people start caring about this.
@stephenmok at this point I don’t care anymore that the DS team has created an artificial wall of cognitive dissonance around itself to prevent you from feeling any responsibility towards the end product and the consumers of your packages. Either the DS team starts taking responsibility, or the DS team has no business in pretending to have ownership of any of the AtlasKit packages.
I assume you don’t depend on that package directly and it’s a transitive dependency so you should try running this command: npm update @atlaskit/platform-feature-flag
or yarn upgrade @atlaskit/platform-feature-flag
@TonyGoughAdaptavist Could you also please share what kind of bundler (name + version) you are using to build your FE code?
Thanks Remie, that makes sense. We do have some configuration in our bundler (Vite) to enable us to use process.env in our own code but either it was not being applied to libraries in node_modules or perhaps the issue was these variables need to start with VITE_ for us (so a replacement could be a solution as you suggest) I’ve not looked into it further for now as the new version has fixed this.
@madamczak Can confirm the new version fixed the issue. We use Vite, version 2.9.15 at time of writing.
