Hi @DanielDelCore ,
By moving to a one-way mirror for Atlaskit, Atlassian is making it hard for other people to work with the code. If I wanted to use a specific Atlaskit component version in a product, I used to be able to pull from the atlaskit-mk-ii repo, check out the “my-component@1.2.3 tag”, and find exactly the code I needed. I can also easily diff historical versions of a component to see why (say) upgrading from 1.2.1 to 1.2.3 broke my app.
By moving to this one-way weekly sync, all of the tags are gone, so I can really only see whatever is the tip-of-tree and there is no way to find a specific version of a component. And is this tip-of-tree code representing code that is released, work-in-progress, or something else? There’s no way to tell without checking the individual package.json. The commits are also applied without any history, so you also can’t even easily see changes between the bigger mirror syncs (“git pull” always yields “fatal: refusing to merge unrelated histories”).
And given that the sync only happens weekly, I wonder if the sources for versions of some of the components might be omitted entirely from the mirrors (what happens if a component is upgraded twice within one week?).
These issues were previously mentioned here in slightly more detail:
If you can’t share the internal repo, it would be helpful if at least the external repo could be made functionally equivalent. Having all of the tags brought over and applied to the correct commits would be helpful, and finding a way to mirror individual commits (minus the parts of the repo that contain closed-source code) would be even more helpful in restoring equilibrium.
Scott