1. Dev velocity (faster development)

Reactstrap component library on NPM

Reusable components can speed your app’s development, dramatically.

But, grouping reusable components in a library can also create a pitfall that can slow down future development. This happens when every change to a component has to go through the library’s source repository and its owners.

This happens because a component library is a little bit like a music CD-Rom. If you want to modify a piece of it, you’d have to access the original repository, make change, and re-publish the whole project.

This process can impair the adoption of your libraries, as developers may hesitate to use them knowing they will have to go through the source repository and its owners to make even the slightest change.

This in turn can lead to more re-implementations of the same components, which the organization’s infrastructure team will somehow have to manage. As a result, instead of having developers adopt the library you’ll end-up having to enforce it. This can be a tough road to travel.

To make the library easier to adopt, it’s important to enable its consumers to make changes when they’re needed.

For example, some companies group components into different libraries for different teams or for different themes. When your team owns the repo, it’s easier to make changes. However, over time, you might end up with multiple libraries containing overlapping components with slight differences.

In my (subjective) view, this problem can be solved using Bit. Adding Bit to the library doesn’t require any refactoring, and makes every component available to discover, install and even develop from any other project.

Changes to components can be synced between projects (updates, cross-repo merge etc..) while kept under control. Here’s an example React app, and its matching component collection, and a short video demo.