1. Zero refactoring: any repository is a monorepo

Bit can be used to publish any set of files from any repository as a package, without having to refactor the repository’s source code or file structure. At all.

Instead, Bit can be pointed to the relevant packages (components, modules etc) from the repository, which it will then seamlessly isolate, tag with a version, and wrap with a unique environment.

The isolated components and modules can then be installed with NPM/Yarn in other projects, or imported using Bit itself for further development.

Here’s an example React App on GitHub.

You might have missed it, but Bit was added to this project and was used to make all the UI components in the repo available as NPM packages.

The repository now effectively became a multi-package monorepo, even though not a single file or code-line was changed. You can do the same for your own repository, to save a lot of refactoring time and effort. This is also useful for shared libraries containing multiple shared components/modules.

Original repository:

Shared components:

2. Any set of files is a package (abstraction)

Another useful aspect of Bit is abstraction. Using Bit, you can define the code found in any path in the repository as a reusable component.

So, you are not bound to “packages” in a specific directory or structure and can easily turn any module, from a core ingredient to the smallest function, into a package. The repository’s structure will remain intact.

This ability is useful when sharing many components from a single repo, and makes Bit flexible enough to play well with other tools in the ecosystem.

For example, you can combine Bit and Lerna to handle the core packages in the repo and also easily publish and manage hundreds of smaller components.

3. Automatic dependency management

A basic Lerna monorepo structure looks like this:

my-lerna-repo/

package.json

packages/

package-1/

package.json

package-2/

package.json

As you can see, every package requires its own package.json file in which the dependencies for the package are defined and managed.

Bit uses an automatic dependency definition mechanism, which saves a lot of time and effort. Here’s how it works:

When you define a set of files as a component (using bit add ), Bit will run through the code and identify both file and package dependencies.

), Bit will run through the code and identify both file and package dependencies. If it detects a file dependency, you can either add it to the component or turn it into a new dependent component. These dependencies will be seamlessly managed in the component’s bit.json file.

file. If Bit detects a package dependency for the component, it will create a package.json file for the component and manage it there.

You can learn more about it here.

When working inside the project and a new component/package version is available, Bit will prompt about it in the bit status command and you can decide what to do about it. In the near future, you will be able to define a pro-active event-driven update strategy. Either way, time and work are saved.

With Bit you don’t have to constantly define and configure the dependency chain for the packages in the repo. Bit does that for you to save overhead.

4. No package-specific build/test configurations

One of the major overhead-generators around a multi-package repo is the environment (build, tests etc.) configurations needed for every package.

Bit eliminates this overhead by letting you import pre-made environments into the project’s workspace before publishing the components. You can choose environment from this pre-made collection, or create/extend your own build and test environments.

Bit uses these environments to build and test every component/module individually in isolation from the project, and the results are presented in the component’s screen in Bit’s web UI.

React spinners shared from a single repo

Based on this process, it can even add more cool features like a live playground to play with the components before using them.

5. Code discoverability