Re.Pack 5.2: Faster Babel Transforms, RN 0.80 & 0.81, Rozenite

Re.Pack 5.2 is a big, non‑breaking release focused on two things: a modern, parallel Babel & SWC transform pipeline, which dramatically improves performance in Babel-heavy codebases, and a smoother developer experience. It also introduces official support for React Native 0.80 and 0.81.

Besides these headline features, you get fully typed configs for both Rspack and webpack bundlers, and support for enhancing the React Native DevTools with the Rozenite plugin framework along with few other minor enhancements. Read on to see what’s new and how to use it to full potential.

Transformation pipeline: fully parallel and smarter

Up until now, Re.Pack relied on a mix of tools to get your source code to something React Native runtime (i.e. Hermes or JSC) can understand. This was especially true when using Rspack as a bundler. We relied on tools like flow-remove-typesand custom workarounds to minimize the performance impact of Babel transforms. It became clear that sustaining this workflow is unfeasible and required changes. It was, in fact, the main issue that blocked supporting newer versions of React Native up until this point.

In 5.2, @callstack/repack/babel-swc-loader becomes the new, recommended way to transform JS source files with Re.Pack. This new loader seamlessly combines Babel with SWC by analyzing the presets and plugins for each file. When possible it schedules supported transforms for fast, Rust-based SWC and otherwise uses good ol’ Babel for the rest. In practice, every file will go through Babel first and then SWC will finish the job.

Combining Babel and SWC like that is only a part of the story. To make it a feasible replacement it needed to be fast. While SWC in Rspack is already natively parallelized, babel-loader on it’s own is inherently single-threaded. By taking a play from Metro’s playbook & utilizing Parallel Loaders capability from Rspack we can achieve full parallelization from start to finish reducing cold compilation times 2.6x: from 52.4s to 19.8s.

In projects where SWC alone can’t handle everything, this new approach can be much faster. As soon as you add any Babel plugins to the project configuration, it easily outperforms the previous strategy. The best example that illustrates the benefits of babel-swc-loader is the use of heavy plugins like React Compiler. It used to make Re.Pack builds unusably slow, drastically increasing compilation time. Now, the overhead is smaller or comparable to that which you get in Metro when using the React Compiler.

In our benchmarks, this increasingly more common scenario, as React Compiler steadily approaches stable release (currently in Release Candidate phase, results in 2x faster compilation: from 39,5s to 19.9s.

The new loader is almost a silver bullet. In cases where you are not using any custom Babel plugins, the old approach is still faster. SWC does 95% of the job and Babel is limited to running codegen transforms, needed for the New Architecture builds. Realistically speaking, in smaller projects the difference between the two approaches should be much smaller and build performance degradation should not be noticeable.

Performance aside, with @callstack/repack/babel-swc-loader you can add plugins to your babel.config.js like in Metro, and there is no need to touch anything else in the configuration. It just works 🚀

To use it in your project, replace getJsTransformRules() with the following:

// rspack.config.mjs
export default {
  module: {
    rules: [
      {
        test: /\.[cm]?[jt]sx?$/,
        type: "javascript/auto",
        use: {
          loader: "@callstack/repack/babel-swc-loader",
          parallel: true,
          options: {},
        },
      },
      // ...
    ],
  },
};

Using babel-swc-loader with webpack

The new loader is also compatible with webpack configurations, and it can automatically use SWC to optimize the build time there too. All you need to do is install @swc/core and @swc/helpers in your project and you should be good to go. In cases where SWC is not available in the project context, the loader will fallback to using just Babel for the whole process, making it an universal approach regardless of the bundler used.

Every new Re.Pack project created will now use @callstack/repack/babel-swc-loader as the default way of transforming JS files—both in Rspack and webpack configurations.

Support for React Native 0.80 & 0.81 support

This release also bring official support to the newest React Native versions: 0.80 & 0.81. The reworked transformation pipeline allowed us to skip a lot of custom workarounds we had in place like minimizing impact of Flow transformations through flow-remove-types. They are now handled the official way, through a dedicated Babel plugin.

If you are using Re.Pack with Rspack together with the getJsTransformRules helper in your configuration, only React Native 0.80 is fully supported. Newer React Native releases include changes that forced us to introduce the new hybrid Babel & SWC approach. Because of that, React Native 0.81 is supported officially only through using @callstack/repack/babel-swc-loader.

TypeScript configurations

Re.Pack 5.2 adds first‑class support for .ts, .mts and .cts configuration files in both Rspack and webpack, and introduces helpers to type your configuration end‑to‑end. The new defineRspackConfig and defineWebpackConfig helpers improve editor autocomplete and catch mistakes earlier. This pairs very nicely with the native type stripping available in Node 24 and Node 22.

Helpers wrap your entire configuration like this:

// rspack.config.mts
import * as Repack from "@callstack/repack";

export default Repack.defineRspackConfig((env) => ({
  resolve: {
    ...Repack.getResolveOptions(),
  },
  module: {
    rules: [
      {
        test: /\.[cm]?[jt]sx?$/,
        type: "javascript/auto",
        use: {
          loader: "@callstack/repack/babel-swc-loader",
          parallel: true,
          options: {},
        },
      },
      ...Repack.getAssetTransformRules(),
    ],
  },
  plugins: [new Repack.RepackPlugin()],
}));

Typed configs mean the entire surface (environment function, rules, plugins, and helper utilities) benefit from static types. Even in plain JS files, your IDE can pick up on those types, hence why every new project created with Re.Pack now comes with those helpers included in the configuration.

Make sure the check out the section on TypeScript Configuration in our documentation!

Rozenite support

Since Re.Pack 5 release, the integration with the official React Native DevTools has been has been constantly refined, and we bridged even more gaps in this release. This opens the door for tools like Rozenite to integrate with Re.Pack. With it, you can add plugins to your DevTools, enhancing debugging experience with Network Activity panel or specialized add-ons for libraries like Redux or MMKV - allowing you to inspect the state of the app in a convenient manner.

To get started with Rozenite in your Re.Pack project, simply install it in the project and wrap your existing configuration like this:

// rspack.config.mjs
import * as Repack from "@callstack/repack";
import { withRozenite } from "@rozenite/repack";

export default withRozenite(
  Repack.defineRspackConfig({
    // Your existing Re.Pack configuration
  })
);

For more detailed instructions, check out the official Getting Started with Rozenite guide.

Other notable changes

We’ve also landed a series of quality‑of‑life updates for a smoother development experience along with some extra features.

Rspack compilation progress in development is now visible as a progress bar and webpack progress updates have been aligned to look the same, instead of noisy repeated messages:

You can now open a stack frame’s source directly from an error screen and it will take you that place in your editor:

Other changes include:

• React Native DevTools sources tab is now much tidier thanks to proper formatting of paths outside of project root directory
• Re.Pack now ships with Terser plugin preconfigured, so there is no requirement to configure it explicitly in your configuration for optimized production builds
• ScriptManager now fully supports the file:// protocol when loading (Android) and prefetching (iOS) scripts
• Code-signing signatures can be now verified for the bundles loaded from the device filesystem
• You can now customize SVGR through additional options passed to getAssetTransformRules
• Package Exports support has been improved and react-native condition is now properly resolved before import or require conditions
• Support for 16kb page size on Android

Special thanks go to Community Contributors: https://github.com/ilteoood, https://github.com/tringenbach, https://github.com/longb1997

Upgrade guide

Upgrading is straightforward and there are no breaking changes in this release despite the vast amount of features & fixes included. Simply updating the @callstack/repack version in your package.json to 5.2.0 will do the trick.

To make the most out of this release, make sure to replace getJsTransformRules helper (Rspack) or babel-loader (webpack) in your configurations files. Since the official @react-native/babel-preset is at the heart of it all, make sure you have it installed in the project and it is present in the babel.config.js file.

Lastly, make sure to upgrade the @rspack/core version in your project too. We recommend upgrading to the latest version of Rspack 1.5.0 to have everything running smoothly. If you are using webpack you should be fine as it is, but it’s good to give it a version bump too.

Community effort: Expo Router support

One of Re.Pack open source contributors - Carlos Paludetto - managed to get Expo Router working with Re.Pack. If you are curious about such use case, be sure to check out his blog post detailing the setup needed to get this working. Our one and only thymikee also made a rundown on this subject:

What’s next

With the new universal hybrid transformation pipeline, our goal is to strike the right balance between performance and full compatibility for React Native projects. The migration from Metro should be even simpler than before, removing the needed for creating custom rules to bridge custom babel.config.js files.

This release took quite some time to deliver and we feel like we can do better in that regard. We will look into publishing nightly releases to make it easier to use the newest fixes & features as soon as possible.

In near future, we will also focus on delivering first class support for @callstack/react-native-sandbox. It’s a new library from Callstack Incubator for running multiple, isolated React Native instances within a single application. Our goal is to ensure it works seamlessly with Module Federation through Re.Pack, so that the context and data of your mini apps (federated modules) can’t leak. Stay tuned!

‍