How to Easily Reuse Components Across Projects and Repositories

Build, distribute and collaborate over components to build multiple projects and applications — a practical guide.

Components drive the development of modern applications. Apart from being UI elements that form the experience for your users, they are also reusable and modular code units which should often be used in more than one project.

When you start diving into the world of building a shared component architecture for your organization, you end up having to figure out some tough questions such as how to develop components independently but avoid the overhead of too many repositories, how to version, publish and manage each component individually, how to help others discover and adopt the components and so on.

These are deep questions, which range from the monorepo experience of component development to cross-repository management of components, and beyond. In this post, we’ll see how you can leverage useful tooling and workflows to develop, distribute and adopt components across projects.

Framework/no framework

You basically have two choices here. The first is to use a framework like React, Angular or Vue. The advantage is that you can enjoy all the scaffolding and advantages of the well-matured framework.

But, you can also choose web-components and their tooling like Stencil etc. The advantage is that these components are framework agnostic, which helps reuse and utilize components in projects based on different frameworks.

Monorepo experience for multiple repositories?

You have to figure out which architecture is right for you. To avoid the overhead of developing each component in a standalone reposiotry, many teams choose to group components into component libraries.

Designated tools like Bit (GitHub) let you develop, build and test individual components in the library in complete isolation. Using Bit, each component in any reposiotry (and library) can be tracked as a standalone unit, and automatically packed it with all its dependencies. Then components can be independently linked to a compiler (zero configs needed), to that they can be built, tested and rendered in isolation. Then, multiple components can be versioned and published from the repository. When you update a single components, Bit “knows” which other components depend on it, and help you update all the component that are impacted by the update.

It also provides additional “monorepo-like” features which are very useful for code-sharing, such as automatic local linking, multi-component configurations control, subsets and incremental builds, cyclic dependencies handling, dynamic workspaces, single NPM install and more.

Another option is to refactor all projects to a monorepo, but that is a massive decision and isn’t required just to share code. You can also use other great aid tools (like Lerna) to version and publish components from the repo, but most will require extensive refactoring and configurations and don’t control the dependency graph of components. Either way, try and see what works.

Distribution and consumption across repositories

When you publish your components things are far from over. You have to make sure people can practically find, use and update the components.

Otherwise, you risk puting in all this work for nothing; most people won’t go through much bother to seek your components and won’t adopt components that they can’t modify if they have to. Diving into the whole library and updating it just for one component can be a cumbersome process.

Set up a shared component portal; Make it looks good!

Create your component hub in bit.dev

To bring everyone together on your shared components and to consolidate the discovery and consumption of components, you can create your own component portal or just use a cloud-based portal like bit.dev.

The key ingredients provided by such a portal are:

Finding components shared by your team.

Learning about their APIs and playing with live rendered examples.

Consuming individual components to use in different projects.

Ideally, running build and tests for every component.

If you build it on your own, it might take a while but it’s possible. If you choose bit.dev, you get all of the above out-of-the-box alongside features for managing permissions, controlling workflows etc. It will host your components, run their CI, let you save and play with rendered code examples, extract API docs for components and let you install them using npm/yarn.

bit.dev- find, learn, try and install components

Enable single or bulk components update; not the whole library

You can leverage Bit to version and publish individual components from a reposiotry, and even publish multiple components together as a bulk.

When you make changes to one component, Bit will let you update the version only of the component itself and the components depending on it in the reposiotry, so you don’t have to bump the whole library.

Then, the consumers of these components can get updates only for the components they install (and their dependents), without having to bring in redundant updates for the whole library.

Enable component modifications and updates from any consuming repository; manage and control changes across projects

When you publish components to bit.dev you can do more than just install them as packages; you can bit import the actual source code of the components into any consuming repository. No context switching and you don’t have to dive back to the publishing repo to suggest your changes.

This “cloned” version of the component comes with all the relevant files and dependencies, a linked compiler, and is versioned and managed by Bit. As a result, you can just edit the code and run the build+tests in isolation.

When you are happy with the result just bit tag a new version and export it back to bit.dev. The changes can then be updated into any other project, including the original publiching library. Changes can be merged using Git inside the repo so that you can easily sync component changes everywhere.

Component design system for developers

When you build and share components you are really building a UI component design system. This system has the power to standardize your development and consolidate a consistent and happy visual and functional experience to the users of your applications.

Only instead of just a library, you get a living and breathing component ecosystem within the organization. Instead of a static docs site, you get a component hub with visually rendered components where everyone can easily find, view and even play with the actual components you build.

Visual design system with actual code components