# Utoo: a Rust package manager and Turbopack bundler behind one CLI

> Utoo wraps a Rust package manager, a Turbopack-based bundler and a WASM build of the same toolchain into one command set. It is worth a look if you already live in Node and want webpack compatibility, and it is a bad fit if you need a stable CLI contract today.

**utooland/utoo** — A unified toolchain for web development

- Repository: https://github.com/utooland/utoo
- Website: https://utoo.land
- Stars: 2,549 · Forks: 128
- Language: Rust
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/utooland-utoo

## What Utoo replaces, and for whom

Utoo is a single frontend toolchain that bundles three jobs that normally need three tools: dependency installation, module bundling, and script or package execution. The README describes it as combining "a fast package manager, a powerful bundler, and a flexible command system into a single, cohesive ecosystem." The Rust core lives in `crates/`, the TypeScript packages in `packages/`, and Turbopack source is pulled in as a git submodule under `next.js/`.

The intended user is a Node developer or monorepo maintainer who already knows npm and webpack and does not want to relearn both. The repository's `package.json` declares npm workspaces across `packages/pack`, `packages/pack-cli`, `packages/utoo-web` and roughly twenty example projects, so the maintainers are building for their own monorepo first. The `examples/` directory is the clearest statement of scope: `with-react`, `with-antd`, `with-less`, `with-sass`, `with-tailwind`, `with-postcss`, `with-swc-plugin`, `webpack-compat`, `split-chunks`, `externals`, `resolve`, `with-nodejs`.

If your project is a plain single-package app with no webpack config and no monorepo, the unified pitch buys you less. You would be trading a well-understood npm plus Vite or webpack setup for a toolchain whose README is thinner than the repository behind it.

## How the pieces fit: Rust core, NAPI bindings, WASM build

The Cargo workspace lists nine members: `crates/pack-api`, `crates/pack-cli`, `crates/pack-core`, `crates/pack-napi`, `crates/pack-schema`, `crates/pack-tests`, `crates/pm`, `crates/ruborist`, and `crates/utoo-wasm`. `crates/pm` is the package manager behind the `utoo` and `ut` commands. `crates/ruborist` is a separate crate in the same workspace, which suggests dependency resolution is factored out from the command layer rather than embedded in it. That separation matters if you ever want to call resolution without the CLI.

`crates/pack-napi` is the Node bridge, and the workspace pins `napi` 3.10.0 with the `napi3`, `napi4`, `napi5`, `serde-json` and `tokio_rt` features. So `@utoo/pack` is a native addon, not a JavaScript reimplementation. `crates/utoo-wasm` is the other half of the same story: the README says `@utoo/web` is the "Web-compatible version of the toolchain (WASM, Browser-based bundling)," which means the same core is compiled twice, once to a native module and once to WebAssembly. That is a real architectural commitment, and it explains why `examples/utooweb-demo` exists.

The bundler itself is delegated. The README states `@utoo/pack` is "powered by Turbopack," and the `next.js/` submodule is described as "Turbopack source integration." Utoo is therefore not writing a bundler from scratch; it is wrapping Turbopack and adding a CLI, a config layer (`crates/pack-schema`, `packages/pack-shared`) and a webpack compatibility path. Read the project that way and the feature list makes sense.

## Installing Utoo and running a first build

The README gives three install routes for the core toolchain: Homebrew for macOS and Linux, a global npm install, and Cargo for building from source. Pick one.

```bash
brew install utooland/tap/utoo
npm install -g utoo
cargo install utoo-pm
```

The npm route installs the `utoo` package globally, which is what puts `ut` on your PATH. The bundler is a separate install and is meant to be a project dependency. The README shows `ut install @utoo/pack --save-dev` for the bundler and `ut install @utoo/pack-cli --save-dev` for the CLI wrapper, then `ut install @utoo/web --save` for the browser build.

```bash
ut install @utoo/pack --save-dev
ut install @utoo/pack-cli --save-dev
```

For a first real use, the README's bundling examples go through `utx up`. The `up` command is described as a shortcut alias for `utoopack`, and `@utoo/pack-cli` is a "lightweight wrapper to run `up` commands." Three invocations are documented: a dev server with HMR, a production build, and a production build against an existing webpack config.

```bash
utx up dev
utx up build
utx up build --webpack
```

The third one is the migration path worth testing first. If your project already has a `webpack.config.js`, `utx up build --webpack` is the command the README says will use it. Note the discrepancy: the package management section writes `ut install`, `ut add lodash` and `ut x create-react`, while the bundling section writes `utx up`. The README does not explain the relationship between `ut`, `utx` and `utoopack`, and it does not document what `utx` resolves to. Check `ut --help` and `utx --help` on your machine before scripting anything.

Utoo also supports pinning a release per project through a `packageManager` field:

```json
{
  "packageManager": "utoo@1.1.8"
}
```

The README explains that when a local dependency command runs under a different Utoo version, Utoo downloads the matching platform package, verifies the registry checksum, caches it under `~/.cache/nm.utoo-self-pin/<platform>/<version>`, and re-executes with the same arguments, working directory and exit behavior. Warm caches work offline, and an invalid cached release is never executed. The handoff covers local install, add, uninstall, update, rebuild and deps commands; scripts, `ut x`, query commands and global installs keep using the current executable. `UTOO_SELF_PIN=0` bypasses it, and pinned entries can be removed with a command like `utoo clean _utoo-self-darwin-arm64@1.1.8`.

## Where the webpack compatibility mode stops

The README's own wording is the honest part: "Partial support for existing Webpack configurations." Not full. The feature table says "Seamless migration with Webpack compatibility mode," which oversells what the bullet below it admits. Treat `--webpack` as a starting point for evaluation, not a guarantee that your config transfers.

The repository gives you one way to find the boundary: `examples/webpack-compat`. Whatever that example contains is the compatibility surface the maintainers keep working. If your config depends on a webpack plugin or loader that is not represented there, you are on your own. The README lists none of the unsupported options, and `crates/pack-schema` is the schema crate that would define the accepted config shape, but the README does not reproduce it. That is a documentation gap you have to close by reading the schema or the example.

There is a second, quieter limitation. Utoo's bundler is Turbopack, and the `next.js/` directory is a git submodule. Cloning the repository without submodules leaves that directory empty. The README does not mention `git submodule update --init` anywhere, so a contributor following only the README will hit a confusing build failure.

## The package manager's self-pinning handoff

The `packageManager` field is the most concretely specified feature in the README, and it is also the one with the most operational surface. The mechanism is a re-exec: a local dependency command that runs under a mismatched Utoo version does not fail and does not silently proceed. It fetches the pinned version for the current platform, checks the registry checksum, caches the binary, and hands off with the same arguments, working directory and exit behavior.

The cache path is `~/.cache/nm.utoo-self-pin/<platform>/<version>`, which is outside the project. On a shared CI runner or a container that does not persist `$HOME`, every job re-downloads. The README says warm caches work offline, so the cost is a cold-cache network round trip per job, not a hard failure.

The scope carve-out is the part to read twice. The handoff applies to local install, add, uninstall, update, rebuild and deps. It does not apply to scripts, `ut x`, query commands or global installs, which "keep using the current executable." So a `postinstall` script running under a pinned project still executes with whatever Utoo invoked it. If your build correctness depends on one version everywhere, the pin does not cover the script path, and `UTOO_SELF_PIN=0` exists to turn the whole mechanism off when it gets in the way.

## Utoo against webpack, Rspack and npm

The comparison that matters depends on which half of Utoo you are replacing.

For bundling, the closest structural alternative is Rspack, which also implements a webpack-compatible API in Rust. The difference in approach: Rspack reimplements the webpack plugin and loader interfaces as the product, so compatibility is the goal. Utoo delegates to Turbopack and offers `--webpack` as a compatibility mode alongside its own config path. If your reason for moving is "my existing webpack config must keep working," Rspack's design is aimed squarely at that, and Utoo's README describes its own support as partial.

For package management, the alternative is npm itself, which Utoo claims to be compatible with. The README gives `ut install`, `ut add lodash` and `ut x create-react` as npm-shaped commands. The real difference is the self-pinning behavior, which npm does not have in this form: npm's `packageManager` handling comes from Corepack. Utoo's version downloads and checksums a platform binary into `~/.cache/nm.utoo-self-pin/`, which is a different mechanism with a different cache location and a different scope carve-out.

A third option is to take neither half. If you only want a faster installer, you can keep webpack or Vite and swap in a different package manager. Utoo's value proposition is the combination, and the combination is what you would be evaluating.

## Maintenance, licence and what a version bump costs

The repository is not archived, and the last push was on 2026-09-28. Recent releases are close together: `utoopack-v1.5.22` on 2026-09-26, `utoopack-v1.5.21` on the same day, and `utoo-v1.1.10` on 2026-09-26. Two bundler patches in one day is a normal cadence for a project at this stage.

The upgrade cost is uneven across the two halves. The bundler moves on `1.5.x` and the package manager on `1.1.x`, so they version independently. A `packageManager` pin of `utoo@1.1.8` in your `package.json` pins the package manager only; it does not pin `@utoo/pack`, which is a normal devDependency you would bump separately. The README does not document rollback for the self-pinning cache, beyond the note that an invalid cached release is reprovisioned from the registry and the `utoo clean` example for removing a pinned entry.

Licence is MIT, declared in both the README's licence section and the `[workspace.package]` block of `Cargo.toml`. That is permissive and imposes few obligations on how you redistribute or modify it. One inconsistency worth knowing: the root `package.json` carries `"license": "ISC"` while the repository licence and the Cargo workspace both say MIT. The root `package.json` also has an empty `description`, empty `keywords` and empty `author`, so it is not the file to trust for metadata. This is a description of the files, not legal advice; if licence terms matter to your organisation, read `LICENSE` directly.

## Conclusion

Adopt Utoo if you want to try a Rust package manager and a Turbopack bundler without leaving npm conventions, and you are comfortable reading the repository when the README is silent. Do not adopt it as the only toolchain for a team that cannot tolerate a CLI whose documented flags disagree with its examples, or that needs a documented rollback path. Verify first that `ut install`, `utx up dev` and `utx up build --webpack` behave as the README describes on your own project, and that the `packageManager` pin resolves for your platform.

## FAQ

### What is Utoo?

Utoo is a frontend toolchain that combines a Rust package manager (`utoo`, aliased `ut`), a Turbopack-based bundler (`@utoo/pack`), a bundler CLI (`@utoo/pack-cli`) and a WASM build for the browser (`@utoo/web`). The README describes it as providing a unified and optimized experience across package management, building and workflow automation.

### How do I install Utoo?

The README gives three routes for the core toolchain: `brew install utooland/tap/utoo` on macOS and Linux, `npm install -g utoo` cross-platform, or `cargo install utoo-pm` to build from source. The bundler is installed separately into a project with `ut install @utoo/pack --save-dev`.

### Can Utoo build using an existing webpack.config.js?

The README lists `utx up build --webpack` as the command for building with `webpack.config.js`, and the repository includes an `examples/webpack-compat` project. The same README describes webpack support as partial, so not every configuration is expected to transfer.

### How does the Utoo packageManager pin work?

A `packageManager` field such as `utoo@1.1.8` makes local dependency commands download the matching platform package, verify the registry checksum, cache it under `~/.cache/nm.utoo-self-pin/<platform>/<version>` and re-execute with the same arguments, working directory and exit behavior. The README states the handoff covers local install, add, uninstall, update, rebuild and deps, but not scripts, `ut x`, query commands or global installs.

### Is Utoo actively maintained?

The repository is not archived, and the last push was on 2026-09-28. Recent releases include `utoopack-v1.5.22` and `utoo-v1.1.10`, both dated 2026-09-26.

### What licence does Utoo use?

The README's licence section and the `[workspace.package]` block in `Cargo.toml` both declare MIT. The root `package.json` carries an ISC licence field instead, which does not match the other two.

## Sources

- [License: MIT](https://github.com/utooland/utoo/blob/next/LICENSE)
- [Project website](https://utoo.land)
- [README](https://github.com/utooland/utoo/blob/next/README.md)
- [Releases](https://github.com/utooland/utoo/releases)
- [utooland/utoo on GitHub](https://github.com/utooland/utoo)

---

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