# BuilderIO/mitosis: One Component Source That Compiles to React, Vue, Svelte and More

> Mitosis is an MIT-licensed TypeScript compiler that turns a single component definition into native code for React, Vue, Angular, Svelte, Solid, Qwik and Alpine. It is aimed at design-system teams, not at app teams, and its Figma pipeline is the part most people come for.

**BuilderIO/mitosis** — Write components once, run everywhere. Compiles to React, Vue, Qwik, Solid, Angular, Svelte, and more. 

- Repository: https://github.com/BuilderIO/mitosis
- Website: https://mitosis.builder.io
- Stars: 14,422 · Forks: 672
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/builderio-mitosis

## The problem Mitosis solves: one design system, many framework builds

A design system that ships to React, Vue and Angular teams usually ends up as three codebases, or as one Web Components build that every consuming framework wraps differently. The README frames Mitosis as the third option: keep a single source of components and compile to native framework code, which it says avoids "the pitfalls of web components". The intended users are library authors and design-system maintainers, not application developers. The README lists the use cases directly: maintaining a consistent design system across multiple frameworks, syncing design systems from Figma to code and publishing them to npm across frameworks. That is a narrow audience with a specific pain, and the project is honest about it. If you write application screens for one framework, Mitosis has nothing to offer you.

## How the compiler works: a JSX dialect in, framework-specific files out

Mitosis components are written in a JSX-like syntax and compiled per target. The README describes the output as "native framework code" for React, Vue, Angular, Svelte, Solid, Alpine and Qwik, which is the whole mechanism: there is no runtime shim in the compiled output, only generated source for each framework. The repository is a Yarn workspace monorepo. The root package.json declares workspaces for packages/*, e2e/*, e2e/e2e-app/output/* and examples/**/*, and its release script builds four packages before publishing: @builder.io/mitosis, @builder.io/mitosis-cli, @builder.io/eslint-plugin-mitosis and @builder.io/create-mitosis. That tells you the shape of the toolchain: a core compiler, a CLI, an ESLint plugin for the component syntax, and a project scaffolder. The e2e workspace and the e2e/e2e-app/output/* glob suggest that each target framework is exercised by compiling into an app and running it, which is the only way to know a cross-compiler is correct. The examples directory holds three cases: examples/basic, examples/metdata and examples/todo.

## Installing Mitosis and building a first component

The README's quickstart is a single create command, run from an empty directory. It scaffolds a project rather than adding Mitosis to an existing one, so plan for a separate repository if your current components live elsewhere.

```bash
npm create @builder.io/mitosis@latest
```

After the command finishes, the README says to read the README.md generated inside the new project. That generated file, not the repository README, explains the project structure and walks through building and testing components, so treat it as the real entry point. The root package.json requires Node >=16 via its engines field, and the repository pins its own toolchain with .nvmrc and .tool-versions if you want to match the maintainers' setup.

The full walkthrough lives in the getting-started docs at mitosis.builder.io/docs/quickstart/. If you want to see compiled output before installing anything, the project hosts a playground at mitosis.builder.io/playground, which the README lists under Resources. The repository README does not document an incremental migration path for an existing component library, and it does not describe how to add a new compilation target.

## The Figma integration is the differentiator, and the least documented part

The README gives Figma its own section, and the pitch is bidirectional: generate Mitosis components from designs, and keep the code design system in sync with the Figma design system. For a design-system team, that is a stronger reason to adopt Mitosis than the cross-compilation alone, because the alternative is hand-maintaining a Figma library and a code library that drift. The README points to mitosis.builder.io/docs/figma for the details. What the repository README does not give is anything about how the sync is triggered, what happens when a Figma component changes in a way the compiler cannot express, or how conflicts between generated and hand-edited code are resolved. That silence is worth treating as a risk: evaluate the Figma path against your own components before you build a process around it.

## Where Mitosis is the wrong tool, and what to use instead

Mitosis is not a framework and does not try to be. If your components only ever run in React, writing them in a JSX dialect and compiling back to React adds a build step and a syntax to learn for no benefit. The direct alternative for that case is plain React components, or Vue SFCs, or whatever your single framework uses. The more interesting comparison is Web Components, which the README explicitly positions against: it says Mitosis lets you "avoid the pitfalls of web components by compiling to native framework code". That is the real difference in approach. A Web Component is one artifact that every framework consumes at runtime, with the styling, SSR and event-handling compromises that follow. Mitosis produces separate source files per framework, so each target gets idiomatic code and no runtime layer, at the cost of a compile step per target and a component syntax that has to be expressible in all of them. Lit is the natural choice if you want a single runtime artifact and can accept the Web Components trade-offs. Mitosis is the choice if you want the output to look like something a React or Svelte developer would have written by hand.

## Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-07-21. The most recent releases are @builder.io/mitosis@0.14.0 and @builder.io/mitosis-cli@0.14.0, both published on 2026-07-21, with @builder.io/mitosis@0.13.2 on 2026-06-05. The core compiler and the CLI are versioned in lockstep. The version numbers sit at 0.14.x, which is a pre-1.0 line: a minor bump can carry breaking changes to the component syntax or to generated output, so pin the exact version in your build and read the changesets before upgrading. The repository uses Changesets for release management, with a .changeset/ directory and a g:changeset script, so release notes are generated from the pull requests that land. The project is licensed MIT, which permits commercial use and modification; the LICENSE file is at the repository root. The README's contribution section says the maintainers are actively looking for contributors and points at a good first issues list and a Discord. That is a signal about team capacity rather than about the code, and it is worth reading as one: a compiler that targets eight frameworks has a wide surface for a small group to keep correct.

## Conclusion

Adopt Mitosis if you maintain a component library that has to ship as native code for several frameworks, or if you want a Figma-to-code pipeline wired into npm publishing. Do not adopt it as a general app framework: it compiles components, and the repository's own examples are a basic component, a metadata case and a todo. Before committing, verify that your target frameworks are among those the current release covers, and read the README.md inside the generated project, since that file, not the repository README, explains the build and test walkthrough.

## FAQ

### What is BuilderIO/mitosis in simple terms?

It is a compiler that takes components written in one JSX-like syntax and compiles them to native code for React, Vue, Angular, Svelte, Solid, Alpine, Qwik and more. The README's one-line description is write components once, compile to every framework.

### Is BuilderIO/mitosis the same as the cell division process?

No. The name is shared with the biology term, but this project is a TypeScript component compiler from Builder.io, licensed MIT and published on npm as @builder.io/mitosis.

### What is BuilderIO/mitosis used for?

The README lists three uses: keeping a design system consistent across multiple frameworks, syncing design systems from Figma to code and publishing them to npm across frameworks, and avoiding the pitfalls of web components by compiling to native framework code.

## Sources

- [BuilderIO/mitosis on GitHub](https://github.com/BuilderIO/mitosis)
- [License: MIT](https://github.com/BuilderIO/mitosis/blob/main/LICENSE)
- [Project website](https://mitosis.builder.io)
- [README](https://github.com/BuilderIO/mitosis/blob/main/README.md)
- [Releases](https://github.com/BuilderIO/mitosis/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/builderio-mitosis