search

carbon-design-system / carbon-components-angular

An Angular implementation of the Carbon Design System for IBM.
https://angular.carbondesignsystem.com
Apache License 2.0
533 stars 307 forks source link

move to monorepo #818

Closed ninja511 closed 5 years ago

cal-smith commented 5 years ago

CC @joshblack We're planning on executing the move to the carbon monorepo in November ... We can use this issue to track any prep work we need to do or things we should be aware of so we can have a smooth transition.

vpicone commented 5 years ago

@cal-smith whats the motivation for moving into the monorepo?

cal-smith commented 5 years ago

@vpicone Hey Vince ... I'm sure most of the motivation should be self evident but:

I'm sure there's more that I'm missing, but that should cover the ones that immediately come to mind. On the whole it's a net benefit for the ecosystem, our contributors, and our users.

Let me know if you have any concerns 🙂 And don't worry - we won't need to special case the build process for this project 😉

vpicone commented 5 years ago

@cal-smith thanks! Since none of the Carbon team members are experienced with Angular or familiar with this project some of those points don't exactly track for me. Since we won't be contributing to the Angular package, we won't exactly be able to take advantage of any of the 'keeping pace' or simplified contribution advantages.

In regards to "should ensure library support in the event of a maintainer change," this is actually my primary concern. By bringing this package into the mono-repo it implies the Carbon team is at all responsible for the maintenance of this package (which we're definitely not prepared to take on).

cal-smith commented 5 years ago

Since we won't be contributing to the Angular package, we won't exactly be able to take advantage of any of the 'keeping pace' or simplified contribution advantages.

I'm hoping we can change that. A framework shouldn't be the inhibiting factor for contribution. And while members of the Austin carbon team may choose to not contribute, the simplified contribution flow is absolutely relevant for all other contributions.

By bringing this package into the mono-repo it implies the Carbon team is at all responsible for the maintenance of this package (which we're definitely not prepared to take on).

I feel like this deserves a huge [citation needed] ... To flip the issue around - what happens if my team disappears right now? Does Carbon stop supporting Angular? There are too many teams within IBM that rely on the maintenance of these components to continue taking that risk. At present we don't expect to be dissolving as a team any time soon, but by moving the project into the monorepo we can take advantage of all the infrastructure and policies around that.

I want to be crystal clear here - Angular is a first class citizen in the Carbon ecosystem. The sheer inertia behind us means that the Carbon organization as a whole is responsible for it's continued progress.

vpicone commented 5 years ago

@cal-smith I imagine the product teams using the library would rather pick it up than have it live in the monorepo of a team with no experience with Angular, let alone the library itself.

Perhaps moving the project to the carbon org would be a better way to associate it without the additional complexity/maintenance burden of integrating it into the monorepo?

cal-smith commented 5 years ago

I suppose the big question that's emerging here is: How do we support a multitude of frameworks, produced by a multitude of geographically diverse teams, shipping carbon in the least complex and maintenance heavy fashion possible?

Ideologically the monorepo solves a huge number of issues when it comes to the maintenance and collaboration burden of a design system such as carbon - however I've now heard from at least 2 other members that the monorepo simply adds complexity ... if we don't have the bandwidth to tackle the tooling required to make a monorepo an effective solution for cross team collaboration then I'm no longer sure it's a reasonable answer to the above question.

So how do we do it? Ultimately this is one part technical and one part social - On the technical front tooling such as the compliance test suit and perhaps some unified build utilities can help manage our growing universe of packages. On the social front some more deliberate efforts to communicate and cross contribute could help - pretending that we don't work on the same platform helps nobody, pretending that we can't contribute to other projects helps nobody. I don't believe for a second that framework choice is the limiting factor here - we're not the bad guys, we're just like the rest of you.

I realize this isn't a direct answer, but between this and the icons-angular issue this has clearly moved beyond it's original scope.

Big side note here: For a long time the monorepo was positioned as the solution to carbon packaging and contribution. The assumption was the tooling would fall in place and everyone would become part of a single repository - even all the addon packages. I was unaware that the stance on the monorepo had changed (hence this issue) - again, communication is key.

vpicone commented 5 years ago

@cal-smith if I gave the impression I was signaling a shift in Carbon’s official stance, that certainly wasn’t my intent. Just trying to get some more color around my concerns with this effort.

cal-smith commented 5 years ago

Perhaps in the future, considering being abundantly clear that you're looking to express your personal opinion.

Let me know if you have any concrete issues with this proposal, or feedback on how we can make the process easier.

alisonjoseph commented 5 years ago

Hey @cal-smith I'm going to schedule a meeting for us to discuss.

cal-smith commented 5 years ago

Sure :+1: I had some time blocked out with Vince and Josh next week, so we can use that time instead if you want?

cal-smith commented 5 years ago

After some further discussion we've tabled this for now ... we'll definitely investigate moving to the carbon-design-system org, but there's no clear appetite to commit to the level of work that the monorepo will require if we were to move in.