Jonathan Saring

@JonathanSaring

How We Started Sharing Code Between Projects as a Team

The Story of how we share and sync our components and modules between projects as a team using a tool built for the job called Bit.

How we started sharing code as a team

Sharing code is hard. Even for teams working with reusbale UI components such as React components, achieving true reusability is a challenging.

During the past 2 years, our team grew to include more than 15 developers working on multiple projects. Among other things, we are building a web app using Node.js micro-services and React UI components.

With every new feature and every new member joining our team, we found it harder to share code and keep it synced between our projects. Determined to avoid duplications, we considered all solutions from Submodules to Lerna.

However, issues such as publish overhead, discoverability, and maintainability difficulties prevented us from successfully sharing code at scale.

Finally, we decided to build our own solution; an open-source project named Bit which turns components into building blocks which our team can organize, share and sync between our project. Here is what we learned.

Looking for a solution

At first, we considered releasing our different components and modules as an arsenal of micro-packages to NPM. However, the overhead of publishing and maintaining changes across dozens of repos made us quickly drop this option.

We also considered Lerna which is great for publishing multiple packages from a single repository. This solution had two major problems for us.

The first was the fact that we would have to refactor our codebase into several monorepos just to share code. While monorepo can be great for some usecases, we needed a better way to share code without forcing a restructure.

The second problem was that we would still have to manually maintain dozens of packages within that repo, including their configurations and complicated dependency trees. Every change would still mean making changes across different packages in the original repo (and it’s owners).

Since shared libraries wasn’t much of a solution either, we came to realize that we needed a better way to share our code between our project.

We thought of this solution as an “iTunes playlist” for our components, which will make it easy to discover, share and develop them from different projects while keeping changes synced across our codebase.

So, we decided to build Bit. Here is how it works.

Sharing components directly between projects

Bit’s concept is rather simple. Before Bit, we had to create a new repository and publish a new package for every piece of code we wanted to share. Making changes to the package will also have to go through that repo.

Splitting repos just to share code

With Bit, you don’t have to split repos to share code. You also don’t have to restructure out existing project’s codebase (example).

Instead, you can point Bit to parts of any repo we would like to share, use it to automatically isolate them (Bit will define their file/package dependency tree) and share them to a remote location called a Scope (example).

This will not change the existing repo’s structure at all, and it takes literally seconds as Bit will define the dependency graph and all build / test environments can be simply added to the components before sharing.

Sharing components with Bit

From there, these shared components can be easily discovered and installed in other repos using NPM (and Yarn).

When a change to a component is needed, you can simply use Bit to import it’s actual source code into any project you’re working on, make the required changes, and share the new version (to the same Scope or a new one).

When you share changed code back to your Scope, you can even eject it to become a package dependency for your project again.

When a component is changed, Bit keeps it in sync across projects with an event-driven customizable update strategy (still under work). I can suggest and receive modifications from my team members, see if the tests still pass and easily handle dependencies to make vast changes across my codebase.

Example with React components

For example, here is an app with React movie-app components. Using Bit (and without creating new repos) we shared its components into this Scope.

As you can see, it contains a hero component which some of the guys on our team might want to use for different projects.

Discoverability is enhanced with a built-in search engine and visual UI features for the components, from rendering to test results (which Bit runs in isolation) and auto-parsed docs & examples.

Any team member can easily find this component, use in their projects, make necessary changes right from within that project and sync them between their repos. We’ve been using it ourselves with over 500 components and modules.

Conclusion

A demo of Bit (without the NPM workflow)

Bit was born from our own experience of years aspiring to build software with better modularity. It’s being used by our team for over 10 months, and by additional teams and libraries every day.

Using Bit, we were able to effectively kill the overhead of sharing code between our repos and projects. We made our shared code organized and discoverable for our team, cut down the number of repos to maintain and easily collaborate on the development of shared code from multiple ends.

After being put to work for a few months, Bit helped us to create a unified and organized knowledge base of our components and share them across projects.

It’s a community collaborative project, built to make code-sharing both simple and effective. You are welcome to try it out, suggest feedback and help out!

More by Jonathan Saring

Topics of interest

More Related Stories