In addition to npm packages, how do you currently consume them?
@stephenmok , judging from this statement, I’ll assume that you are unaware that there has been no other way to “consume” Atlaskit components for 8 months other than to install their “built” versions by npm. I’ll try to explain, but any member of your team will be able to do a much better job. Here goes…
It has not been possible to build or test any Atlaskit component for 8 months, the time at which you removed access to the Atlaskit build system. In order to do anything but eyeball the files in the current design-system-mirror, a developer needs to be able to install the dependencies for a component.
Try doing a yarn install on any Atlaskit component. The command will fail because a large numbers of dependencies required by any/all of the components are no longer public. It’s good that you’ve spared yourself the response of the GitHub community to this phenomenon.
I hope that this helps to better explain what developers have been saying for so long: the design-sytem-mirror without the build system serves little useful purpose. The mirror doesn’t ship with the “built” versions used for npm distribution, nor can it build those versions. Beyond the mirror, your team IS providing two things of value: the built npm versions of the components and the venerable documentation/examples site that shows how to use these.
Generally speaking, enterprise customers will only use software that enables important problems to be fixed promptly. This means that the software will come in one of two forms: either, one, licensed for a fee with a support agreement (as witih most Atlassian products), or, two, fully open source, so that they can fix those problems by the enterprise itself in urgent circumstances. Atlaskit currently falls in neither category, so it can’t be used by such customers. In our team’s case, working with Atlassian customers in US financial services and healthcare, Atlaskit is no longer an option.
Years ago, Atlassian introduced and promoted Atlaskit to the community with these requirements in mind. The company has every right to change course, but, if doing so, it should first restore the build system and access to all dependencies with a reasonable deprecation period of, say, one year.