What you’ll get:

Building new features or a new app is just Lego-work. You will gradually refactor your app into better modularity, ending app with much faster development and a better, more maintainable codebase.

You will gradually refactor your app into better modularity, ending app with much faster development and a better, more maintainable codebase. Zero refactoring for sharing components - Bit will seamlessly isolate the components so you can export and reuse them. No code changes.

- Bit will seamlessly isolate the components so you can export and reuse them. No code changes. Visual design system made of actual components - You can see how the components look, play with them in a live playground and more.

- You can see how the components look, play with them in a live playground and more. Gradual refactoring - Want to start using TS in your JS app? No problem- you can gradually refactor components in the same repo. Yes.

- Want to start using TS in your JS app? No problem- you can gradually refactor components in the same repo. Yes. Automatic dependency management for your components - Bit automatically defines and updates (when told to) all dependencies for components in the repo, for much easier and faster development. Changed the styling of a component and updated its version? Run bit status and Bit will let you update all dependent components with the new version.

- Bit automatically defines and updates (when told to) all dependencies for components in the repo, for much easier and faster development. Changed the styling of a component and updated its version? Run and Bit will let you update all dependent components with the new version. Reduced learning curve - A new developer can easily jump in, learn which components are available and how to use them.

- A new developer can easily jump in, learn which components are available and how to use them. Better test coverage- Bit will run the unit tests for each component, so you have a very visual and blunt status check on your TDD or lack of it.

b) One team two applications

One team, two apps

So, in this scenario, you have one team working on two or more projects. Classic use cases are web and mobile app, backEnd and frontEnd, or just building multiple applications for different purposes and costumes.

How it looks:

This scenario is usually when real questions begin. On one hand, building a shared library can be a serious overkill at this point. On the other hand, alternatives might not lead to the real amount of code-sharing needed.

Usually, you’ll start seeing duplicated code between the projects. First utility functions, maybe some middleware functions, and finally entire components.

Some people will try to push for a library, but it’s an overkill. Some might even publish one or two small packages they separated from the repos. You’ll start talking about a monorepo, or a multi-package repo with Lerna, etc.

Recommended workflow:

A library is a long-term commitment, takes serious resources to build and maintain, and creates conflicts when the 2 projects have different needs.

At this point, you’d want to keep the source code of the shared components within the projects, but make it easy to reuse and sync the components. Otherwise, you’re bound to grow copy-pastings and your debt will grow deep.

You can use Lerna to refactor the projects into multi-package projects and publish some core packages to NPM. However, the overhead around this workflow will not work well for many smaller components. The project consuming the packages will have a hard time modifying them, as their source code is located in the other project, and serves that purpose first.

Using Bit you can isolate existing components from one project and reuse them in the other one. Then, you can use it to develop the same components from the two different repos at the same time, as the changes versions can be either updated in both projects or shared as separate components.

What you’ll get:

Instantly share common code between the projects - Levering Bit’s component isolation to quickly share existing code and keep it managed.

- Levering Bit’s component isolation to quickly share existing code and keep it managed. Develop the same code from two projects - Bit lets you bring a shared component into a different project and continue to develop it there.

- Bit lets you bring a shared component into a different project and continue to develop it there. Sync and merge changes - Bit will let you update the changes between the project if needed, and even extend Git to merge the changes between them. If not, that’s ok too — just share the changes as a new component.

- Bit will let you update the changes between the project if needed, and even extend Git to merge the changes between them. If not, that’s ok too — just share the changes as a new component. All the benefits of section A above.

c) Two teams two applications

Two teams, two apps

So here comes in a brand new dimension. We don’t need to just share code between our applications, but also between different people.

This means that in addition to the code-sharing workflow, we need to create a workflow where people can practically discover your shared components and collaborate on top of them.

How it looks:

At this point, you have 2 teams working on a few different projects. One team is in NY and the other is in London. Each team has been building their own components, and now you came to realize that they should standardize.

Then, you start thinking- why not share and reuse?

So, you start building a library for both of them. One of the teams is building the library, ideally while collaborating with the other team. Usually not.

Then problems start to emerge. Both teams use React, but one also uses TS and tests components with a different framework. You start discussing the standardization. Design is determined by the design team, but still the different apps have slightly different needs- from margins to anything else.

Then you realize you need to individually publish each component, and start thinking of Bit and Lerna. You also understand that you must create a discoverability portal for the components, maybe StoryBook or a docs site.

Recommended workflow:

So here what we basically want to have is a universal hub where both teams can easily share, discover, use and modify components as needed.

You can create one Bit collection for the two teams, or two collections- one for each team. It’s up to you. If you do have a library (you probably have one), just share the components from the library to a collection.

Once you have the collection, it works as a single hub where both teams can easily share components too, discover shared components, install components as needed, suggest updates and changes from both projects and stay in sync.

Here’s an example from the popular semantic-ui-react library:

Semantic-ui-react library as shared components

What you’ll get:

A universal hub where both teams can easily share components

Discoverability for the shared components - Search the collections, view the components visually, play with them online, view auto-generated API reference docs and more.

- Search the collections, view the components visually, play with them online, view auto-generated API reference docs and more. Each team can modify components shared by the other team right from their own project - The other team shared a great button component but the margins are not right? just bit import the code and modify it. Like the changes enough to reuse them? share the update back out.

- The other team shared a great button component but the margins are not right? just the code and modify it. Like the changes enough to reuse them? share the update back out. Standardization for design and technology.

d) Infrastructure team with multiple consuming teams and applications