# Re.Pack swaps Metro for Rspack so React Native can federate modules

> Re.Pack is a Callstack toolkit that builds React Native applications with Rspack or Webpack instead of Metro, which is mainly interesting if you want Module Federation and a microfrontends architecture on mobile. The repository is a pnpm and turbo monorepo with a release process built on changesets.

**callstack/repack** — A webpack-based toolkit to build your React Native application with full support of webpack ecosystem.

- Repository: https://github.com/callstack/repack
- Website: https://re-pack.dev
- Stars: 1,947 · Forks: 177
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/callstack-repack

## Why a React Native app would leave Metro behind

React Native applications are bundled with Metro, and Re.Pack exists to replace that step. The project describes itself as a modern bundler for React Native applications, powered by Rspack and Webpack, and states that it serves as a drop-in replacement for Metro with enhanced functionality and access to a broad Webpack ecosystem.

The reason to accept that trade is stated in the same paragraph: it is especially useful for implementing microfrontends architecture with Module Federation in your mobile app. Module Federation is a Webpack feature for loading separately built chunks at runtime, and a Webpack based bundler makes it available on a platform where it is not available by default. The topics attached to the repository confirm the emphasis, listing bundler, code-splitting, module-federation, react-native, typescript and webpack.

So the audience is narrow and specific: teams shipping a React Native app large enough to be split into independently built features, usually with several teams or several release cadences, who need those features to be assembled at runtime rather than compiled into one artifact.

The rest of the audience should think twice. If your app ships one bundle, the case for a second bundler is thin, because you gain a large configuration surface and lose the path of least resistance that the React Native toolchain gives you. The documentation itself points to a Quick Start page, an About page, a Configuration guide and an API reference at re-pack.dev, which is the right reading order before deciding.

## Two engines behind one toolkit, and the choice between them

The name on npm is @callstack/repack, and the banner describes it as a toolkit to build your React Native application with Rspack or Webpack. Both are named, and that is a real choice rather than a synonym, because Rspack and Webpack are separate bundlers that the toolkit supports side by side.

That choice determines how much of the existing Webpack ecosystem you can use. A Webpack based setup gives you the whole plugin surface, and that is where the loaders and plugins for assets, transforms and code splitting come from. An Rspack based setup aims at the same configuration, but any plugin that depends on Webpack internals may not behave identically, which is a trade-off to weigh.

The project's own description is careful about this. It calls Re.Pack a toolkit rather than a bundler in the package tagline, and the README also calls Re.Pack a modern bundler for React Native applications, so the toolkit label is not a denial that it bundles. The topics list includes both bundler and webpack, which matches that reading.

The MIT licence covers the package, and the project states that it will always remain free to use, with the code maintained by Callstack as open source work. For a commercial React Native product, that means the bundler layer is something you can read, patch and vendor if you have to, which matters when it sits between you and every release of your app.

## The repository is a pnpm workspace with turbo, biome and changesets

The top level layout is that of a modern JavaScript monorepo, and it tells you how the project is run. The root package.json is private, names the package repack, pins the package manager as pnpm@10.34.5, and requires Node >=24 in its engines field. The workspace file pnpm-workspace.yaml and the lock file pnpm-lock.yaml sit at the root, with turbo.json describing the task graph and a shared tsconfig.base.json for the TypeScript projects.

The directories are separated by role. packages holds the published packages, apps holds the applications used for development, templates holds starter project templates, tests holds test projects, and website holds the documentation site that is deployed to re-pack.dev. There is also a docs folder per package in the packages tree, since the documentation pages linked from the README live under the website source.

The tooling is deliberately modern. Linting and formatting are handled by Biome, with a biome.jsonc configuration at the root and two scripts, lint which writes fixes and lint:ci which only checks. Tests run through turbo, as do the typecheck and pods tasks, and the build script is turbo run build with a dev counterpart that watches. There is a changesets directory and a.husky directory, and a prepare script that installs husky unless the run is in CI, which is the standard pattern for running a git hook only on developer machines.

Two other files are worth a look if you are contributing. AGENTS.md and ARCHITECTURE.md sit at the root, and there are.agents,.claude and.codex directories plus an agent_context folder, which tells you the project now ships guidance for coding agents alongside its human documentation.

## Working with the repository: the scripts that matter

There is no install command in the project documentation, and the npm package is @callstack/repack, with the setup steps living in the Quick Start page of the documentation rather than in a shell snippet you can copy. What the repository does give you is a complete set of scripts, and they are worth reading because they show the intended workflow.

The two fields that decide whether anything runs at all are these:

```json
"packageManager": "pnpm@10.34.5",
"engines": {
  "node": ">=24"
}
```

With pnpm and a supported Node version in place, the everyday commands are the turbo driven ones. The build script runs turbo run build across the workspace, and the dev script is turbo watch build, which rebuilds on change. Type checking and tests are also turbo tasks, typecheck and test. For iOS work there are two more, pods and pods:update, which run the CocoaPods step for the native side.

The lint story is Biome rather than ESLint and Prettier, so npm run lint:ci is the check that a pull request has to pass, and it takes no separate configuration step because biome.jsonc is already in the repository. The formatting rules are enforced through the same command, which is why there is no format script in the root package.json the way there is in many older setups.

The website has its own scripts, website:start and website:build, filtered to the website package, so you can run the documentation site locally without building the whole workspace.

## Changesets drive versioning, and canaries ship alongside

Releases are handled with changesets, and the scripts show the whole lifecycle. A change that affects a published package is described in a changeset, and version-packages runs pnpm changeset version, which bumps versions and updates the changelogs, followed by the lint step. The release script runs pnpm changeset publish, which pushes the packages to the registry.

There is a second, faster path built in. version-packages:canary runs pnpm changeset version with the snapshot flag set to canary, and release:canary runs pnpm changeset publish with the canary tag and with the no-git-tag option, so a canary build is published without creating a git tag. That is a useful thing for a bundler to support, because the fastest way to know whether a change works in a real app is to install the canary and try it.

The release history shows a project shipping steadily. Versions 5.4.0, 5.4.1 and 5.4.2 were published on 2026-09-26 and twice on 2026-10-09, and the repository is not archived, with the last push on 2026-10-16. A patch and a hotfix on the same day usually means a release went out and something in it needed correcting quickly, which is a pattern worth watching when you pin a version.

For consumers, the practical consequence is that the version you depend on is a normal semver range, and the changelog for each package is generated from the changeset descriptions, so the release notes tend to describe intent rather than a list of changed files.

## What Re.Pack does not do for you

There are limits that come from the architecture rather than from the implementation, and they are worth naming before you migrate a project.

The first is that this is a bundler swap, not a configuration flag. Metro is wired into the React Native build pipeline through the platform scripts, and moving to Re.Pack means changing how your bundle is produced, then validating that asset handling, native module resolution and the development server still behave. The documentation devotes a Quick Start page and a Configuration guide to it, which is a hint about the size of the change.

The second is that you take on the Webpack configuration surface. Once you are on Re.Pack you are configuring a bundler with a large plugin ecosystem and its own failure modes, and a build that breaks is a build that blocks your release. The gain from Module Federation has to outweigh that for your project specifically.

The third is scope. The topics list is bundler, code-splitting and module federation, and nothing in the documentation points to asset pipelines, image optimisation or any of the wider tooling that a Webpack user might assume to be included. This is a React Native bundler toolkit, and using it as a general purpose Webpack configuration for a mobile app will leave you building things yourself.

And the fourth is the cost of a fork in the road. Once a project is on Re.Pack, moving back means undoing the configuration work, and the two bundlers do not share a mental model, even though the output is the same application.

## The realistic alternative, and what it costs you

The alternative is the default: keep Metro and do not attempt runtime federation. The difference in approach is not about quality, it is about where the boundaries between features live. With one Metro bundle, the application is compiled as a single artifact, every feature is built and released together, and the release train is one train. With Re.Pack and Module Federation, features are built and shipped separately, and the app assembles them at runtime.

That buys you independent release cadence for features and, in a large organisation, the ability for separate teams to own separate modules without coordinating a single bundle. It costs you the migration work, the extra build configuration, and the failure mode where a federated module cannot be loaded at runtime, which is a failure your users see rather than your CI.

A middle path exists and is worth considering before committing. If the reason you want federation is team ownership rather than runtime loading, splitting the application into several bundles at build time, with each feature behind a navigation entry, may deliver most of the organisational benefit with none of the runtime coupling, and it works with whatever bundler you already have.

The other option is to accept a platform native module for the boundary you actually need, and keep Metro for everything else. The decision therefore comes down to one question: do you need modules to be loaded independently at runtime, or only to be developed and released independently. Re.Pack earns its cost in the first case and not in the second.

## Conclusion

Re.Pack is worth adopting when your React Native product genuinely needs Module Federation, because shipping independently built features as federated modules in a mobile app is a problem the default bundler does not solve. It is the wrong choice for an app with a single bundle, where the extra build system costs more than it returns. Before you commit, read the Quick Start page in the documentation at re-pack.dev and the Configuration guide, since the setup is not a one line change to a config file, and check that the version you pin, currently 5.4.2, matches the React Native version your app uses, because the repository moved to 5.4.0 on 2026-09-26 and then twice on 2026-10-09.

## FAQ

### What is Re.Pack and what does it replace in React Native?

Re.Pack is a toolkit for building React Native applications with Rspack or Webpack, and it serves as a drop-in replacement for Metro. The npm package is @callstack/repack and the documentation is at re-pack.dev.

### Why would a React Native project use Re.Pack instead of Metro?

The project states it is especially useful for implementing a microfrontends architecture with Module Federation in a mobile app, which makes the Webpack ecosystem available on a platform where Module Federation is not available by default. Code splitting is one of the listed topics of the repository.

### What does it take to build the Re.Pack repository itself?

The root package.json pins the package manager as pnpm@10.34.5 and requires Node >=24. The build and test work is driven by turbo, with scripts for build, dev, typecheck, test, pods and pods:update, and linting is handled by Biome through lint and lint:ci.

### How are Re.Pack versions published?

With changesets. The version-packages script runs pnpm changeset version followed by lint, and the release script runs pnpm changeset publish. There is also a canary path, version-packages:canary and release:canary, which publishes a snapshot build under the canary tag without creating a git tag.

### Is Re.Pack still being worked on?

The repository is not archived and the last push was on 2026-10-16, with version 5.4.0 published on 2026-09-26 and 5.4.1 and 5.4.2 both published on 2026-10-09. The project is maintained by Callstack and released under the MIT licence.

## Sources

- [callstack/repack on GitHub](https://github.com/callstack/repack)
- [License: MIT](https://github.com/callstack/repack/blob/main/LICENSE)
- [Project website](https://re-pack.dev)
- [README](https://github.com/callstack/repack/blob/main/README.md)
- [Releases](https://github.com/callstack/repack/releases)

---

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