teambit/bit: component workspaces for JavaScript and TypeScript

What Bit solves, and for whom

The README frames Bit as "the build system to connect components and apps from development to CI in the AI era." Stripped of the marketing, the problem is concrete: a React component or a Node module that three teams need ends up copied three times, or extracted into a package that nobody wants to own. Bit's answer is to make the component the unit of source code, versioning and release, so it can be consumed from a monorepo, a polyrepo, or a workspace with no repository at all. The README states Bit fits every codebase structure.

The audience is teams with reuse pressure. If you maintain a design system, shared hooks, backend services and several front ends, the component model maps onto work you already do. If you write one application and never share code outside it, the concepts (workspace, scope, component ID, tags) are overhead.

The repository itself is the strongest evidence of intent: the README says Bit is entirely built with Bit, and the components live on Bit Cloud under the teambit scope. That is a real dogfooding claim, not a demo.

How a Bit workspace is put together

A Bit workspace is a directory with a workspace.jsonc file and a .bitmap file at the root. Both appear in the top-level repository entries, and workspace-jsonc-schema.json is published alongside them, which means the workspace config is a validated, schema-backed file rather than a loose convention. The .bitmap records which files on disk belong to which component, so a component is not a folder by definition; it is a set of tracked files with an ID.

Components are created from templates. The README calls them "standard building blocks" and describes defining blueprint templates "for devs and AI as one." Templates are installed per workspace and selected by name, so the command surface is template-driven rather than fixed.

Applications are composed as shells. A shell imports components by their package-style ID, and the README's example imports Login from '@my-org/users.pages.login' inside a React Router setup. The same ID is what npm consumers install later, which is the point: the internal import and the published package are the same string.

The AI angle is an MCP integration. The README says Bit "enables AI agents to intelligently create and reuse components via MCP preventing duplication," and a .mcp.json file sits at the repository root. So the agent path is a configuration file plus the same component API, not a separate toolchain.

Install Bit and run a first shell application

The README gives one install path: the Bit installer, which puts a bit binary on your PATH. Node 22.13.0 or newer is required, per the engines field in package.json.

npx @teambit/bvm install

Then initialize a workspace. The --default-scope flag takes an org and project name, and the README tells you to create that scope on the Bit platform first.

bit init --default-scope my-org.my-project

Create an application shell from the official React template and run it. The README says the shell is served on port 3000.

bit create react-app corporate-website
bit run corporate-website

Open http://localhost:3000 to see the shell. From there you create components and compose them into the shell's routes. The README's example creates a login page with bit create react pages/login, then imports it as '@my-org/users.pages.login' into the shell component. Optionally, bit start opens the Bit UI for previewing components in isolation.

Versioning, export and the scope dependency

Releasing is where Bit stops being a local tool. Components are versioned with semantic versioning through bit tag, and the README's example uses --major with a message. By default the build runs on Ripple CI, a hosted product; the --build flag moves the build to the local machine. That default is a real constraint. A team that cannot send source to a hosted build service has to pass --build or wire up its own CI with the official scripts the README links.

Export pushes versions to a scope. The README offers two hosts: Bit Cloud scopes, or a self-hosted scope server. bit login creates the account and the first scope. After export, consumers install components with a normal package manager, for example npm install @my-org/users.pages.login.

The scope is therefore not optional infrastructure you can defer. Without one, components exist only in your working directory and nobody else can install them. The README does not document what happens to a workspace when a scope is unreachable, nor does it describe rollback of a bad export; those gaps matter if you plan to make the scope the release path.

Where Bit is the wrong tool

Bit is a poor fit when your code does not decompose. A single-purpose CLI, a small service with one deployable, or a codebase where every module is used exactly once gains nothing from component IDs and independent versioning. You would pay the workspace and scope concepts for reuse you will never exercise.

The second failure mode is organisational, not technical. Components are only reusable if someone maintains them. Bit makes extraction and publishing easier, but the README does not describe ownership, deprecation or review rules for components, and it does not document what happens when a component is exported and then deleted. Those are the questions that decide whether a shared component survives.

The third is the hosted default. Ripple CI builds components unless you pass --build, and the platform account is part of the documented getting-started path. Teams with strict source-egress rules should read the self-hosted scope and CI-script pages before starting, not after.

Bit against a plain monorepo with npm workspaces

A monorepo with npm or pnpm workspaces and a build orchestrator such as Turborepo or Nx solves a similar problem differently. In those tools the package is the unit: it lives in a directory, it has a package.json, and the workspace manager links it. Versioning and publishing are handled by a separate release tool, and consumers install from a registry.

Bit changes the unit from package to component and makes the component ID the same string you import and install. Versioning is built in through bit tag, and the scope replaces the registry as the publish target. That is a genuine difference in approach, not a rebranding: you get per-component versioning and an internal import that matches the external package name.

The cost is that Bit owns more of your workflow. With npm workspaces you can delete the tool and keep plain packages. With Bit, the .bitmap and workspace.jsonc are the map of your source, and the README does not document an exit path back to plain packages. That asymmetry is worth weighing before you move a large codebase.

Licence, maintenance and upgrade cost

The repository ships an Apache License, Version 2.0 file and package.json declares "license": "Apache-2.0". The GitHub metadata reports the licence as NOASSERTION, which is a classifier artefact rather than a conflict, but anyone automating licence checks should read the LICENSE file directly. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires attribution and notice retention. That is a description of the licence text, not legal advice.

The hosted side is separate. Bit Cloud and Ripple CI are services with their own terms, and the README routes account creation and default builds through them. Self-hosting a scope server is documented as an option, so a fully self-contained setup is possible, but the README does not describe its operational cost.

Maintenance looks current: the last push was on 2026-09-15, and recent releases include v2.0.26 on 2026-07-21, v2.0.11 on 2026-07-08 and v2.0.2 on 2026-06-30. Upgrades are not free, though. The repository pins Node >=22.13.0, and Bit is built with Bit, so workspace and component formats move together with the CLI. A team that upgrades the CLI should expect to revisit workspace.jsonc against workspace-jsonc-schema.json.

Editorial conclusion

Adopt Bit if your team already ships shared UI or modules across several repositories and wants one component model for humans and AI agents. Do not adopt it for a single small app with no reuse plan: the workspace, scope and versioning concepts cost more than they return there. Before committing, verify three things: that Node is at 22.13.0 or newer, that you have a scope on Bit Cloud or a self-hosted scope server, and whether your CI will build on Ripple CI or locally with the --build flag. The Apache-2.0 licence covers the repository; the hosted platform is a separate service with its own terms.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. teambit/bit on GitHub