OpenWikivercel/turborepo

Rsbuild

Purpose and Scope

This page explains how to use Rsbuild as an application framework inside a Turborepo workspace. Rsbuild is documented as an Rspack-based build tool with out-of-the-box setup for modern web applications, while the Turborepo guidance concentrates on monorepo integration: where the application package lives, how it consumes internal packages, how it inherits task definitions, and what changes are needed for microfrontends or module federation. The page belongs to the framework guide family, so it should be read as practical repository setup guidance rather than as a complete Rsbuild manual. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx, apps/docs/content/docs/guides/frameworks/index.mdx, apps/docs/content/docs/guides/frameworks/meta.json

The common reader problem is not whether Rsbuild can build an application in isolation. The harder monorepo problem is making an Rsbuild app behave like every other workspace package so it can be installed, built, developed, and composed through shared repository workflows. Turborepo does not require a special Rsbuild runtime adapter for normal task execution. Instead, the integration boundary is made of package manager workspace membership, package scripts, root and package-level task configuration, and framework-specific configuration for asset paths when several frontends are served together. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx, apps/docs/content/docs/guides/frameworks/framework-bindings.mdx

Relevant Source Files

  • apps/docs/content/docs/guides/frameworks/rsbuild.mdx - Primary Rsbuild integration guide with quickstart commands, existing-repository setup, internal package dependency examples, task customization notes, microfrontend base configuration, and the module federation example.
  • apps/docs/content/docs/guides/frameworks/framework-bindings.mdx - Explains how shared library packages can provide framework-aware bindings with peer dependencies and package export paths.
  • apps/docs/content/docs/guides/frameworks/index.mdx - Defines the framework guide area and states the broad principle that Turborepo works with any framework.
  • apps/docs/content/docs/guides/frameworks/meta.json - Places the Rsbuild page in the framework navigation order beside Next.js, SvelteKit, Vite, Nuxt, and framework bindings.
  • apps/docs/content/docs/guides/frameworks/nextjs.mdx - Provides the comparable framework guide structure and a framework-specific microfrontend base-path contrast.
  • apps/docs/content/docs/guides/frameworks/nuxt.mdx - Provides another comparable framework guide and shows a different base setting used for microfrontend child applications.

Quickstart Path

For a new repository, the fastest learning path is the official Turborepo example named for Rsbuild. The Rsbuild guide points to the example that can be selected with the example flag on the create command. This route gives a working repository shape before you introduce organization-specific conventions. It also lets you inspect how an Rsbuild application appears as a package in a Turborepo workspace, how scripts are named, and how root-level task orchestration can run the app without manually coordinating separate build commands. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx

pnpm dlx create-turbo@latest -e with-rsbuild
yarn dlx create-turbo@latest -e with-rsbuild
npx create-turbo@latest -e with-rsbuild
bunx create-turbo@latest -e with-rsbuild

The four command variants perform the same example bootstrap through different package managers. Choose the command that matches the package manager your repository will actually use, because the package manager is responsible for installing dependencies, resolving workspace ranges, and maintaining the lockfile that Turborepo relies on for repeatable task inputs. After creating the example, review the root task configuration and the Rsbuild app package before renaming scripts or moving files. That review establishes which package scripts will be invoked when you later run repository-level commands.

Adding Rsbuild to an Existing Workspace

When a repository already exists, add the application from the workspace root so the generated package lands inside the repository structure and can be included by the package manager workspace configuration. The Rsbuild guide uses an application path and the React template, matching the common convention of deployable apps under an apps directory. Running the generator from the root also helps keep dependency installation, lockfile updates, and task discovery in one place instead of producing an app that works locally but is invisible to the monorepo workflow. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx

pnpm dlx create-rsbuild@latest apps/my-app --template react
yarn dlx create-rsbuild@latest apps/my-app --template react
npx -y create-rsbuild@latest apps/my-app --template react
bunx create-rsbuild@latest apps/my-app --template react

After generation, treat the Rsbuild application as a normal workspace package. The guide's integration step shows adding an internal package such as the shared user interface package to the app's dependencies. pnpm and Bun examples use a workspace range, while Yarn and npm examples use a star range. The important contract is that the consuming application declares the shared package explicitly, then the package manager installs or links it according to workspace rules. Turborepo's task graph can then reflect package relationships instead of depending on hidden imports. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx

{
  "name": "my-app",
  "dependencies": {
    "@repo/ui": "workspace:*"
  }
}

Do not stop after editing the dependency declaration. The Rsbuild guide also reminds you to run the package manager install command and to update scripts in the application package when needed. That instruction is easy to overlook, but it is central to Turborepo behavior: task execution is driven through package scripts that match configured task names. If the generated Rsbuild app exposes a script name that differs from the root workflow, the app can be valid Rsbuild code while still not participating in the expected monorepo build or development command.

System-to-Code Mapping

The Rsbuild guide is one page in a broader framework section. The framework overview states that Turborepo works with any framework and then offers pages for common integrations, while the metadata file places Rsbuild in that navigation sequence. This positioning matters because the source evidence presents Rsbuild integration as conventions around an application package, not as a new Turborepo command family. The comparable Next.js and Nuxt pages reinforce the repeated pattern: create or add an app, install internal packages, align scripts, customize tasks only when necessary, and set framework-specific base configuration for microfrontends. Sources: apps/docs/content/docs/guides/frameworks/index.mdx, apps/docs/content/docs/guides/frameworks/meta.json, apps/docs/content/docs/guides/frameworks/nextjs.mdx, apps/docs/content/docs/guides/frameworks/nuxt.mdx

Framework bindings are the library-side complement to the Rsbuild application setup. A shared package that needs framework or runtime APIs should make those expectations explicit rather than hiding them inside a generic entrypoint. The framework-bindings guide recommends peer dependencies so the consuming application provides the actual framework version, and it recommends splitting framework-specific entrypoints with package export paths when one library supports several targets. For an Rsbuild app, this keeps shared packages understandable to bundlers, TypeScript, and maintainers who need to know which app supplies which framework dependency. Sources: apps/docs/content/docs/guides/frameworks/framework-bindings.mdx

Task Configuration and Package Overrides

By default, a new Rsbuild application uses the tasks defined in the root configuration. That default is useful because it lets a newly added app participate in repository-wide commands as long as its package scripts use the task names that the root expects. A practical setup sequence is to make the app conform to existing task names first, verify which build and development scripts the generated package provides, and only then decide whether it needs package-level configuration. This keeps the Rsbuild integration consistent with the rest of the monorepo. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx

Package-level task customization is appropriate when the app has a concrete mismatch with the root defaults. Examples include different build artifact locations, different cache output patterns, or a development task that should be treated differently from ordinary finite build tasks. The Rsbuild page points these cases to Package Configurations, which preserves the repository model while allowing one package to override behavior. In practice, avoid creating an override just because the app uses a different framework; create it when the task contract differs in a way that affects execution, caching, or developer workflow.

Microfrontends and Module Federation

Rsbuild has one explicit microfrontend setting in the guide: child applications should set the server base value. Rsbuild uses that value as the default asset prefix for development and production assets, so it helps images, CSS, JavaScript, and other emitted files resolve below the route prefix assigned to the child application. This mirrors the intent of the Next.js base path and Nuxt base examples, but the property and configuration file are Rsbuild-specific. The point is route and asset consistency when several frontend applications are composed locally. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx, apps/docs/content/docs/guides/frameworks/nextjs.mdx, apps/docs/content/docs/guides/frameworks/nuxt.mdx

import { defineConfig } from "@rsbuild/core";
 
export default defineConfig({
  server: {
    base: "/admin",
  },
});

For runtime composition with Rsbuild, the guide separately directs readers to the module federation example. That example is a different starting point from the ordinary Rsbuild example because it demonstrates federated frontend composition rather than just a single Rsbuild application living in a workspace. Use the standard Rsbuild example to learn repository structure, dependency linkage, scripts, and task participation. Move to the module federation example when the actual requirement is runtime composition across separately built frontend pieces, because that architecture introduces coordination concerns beyond ordinary package-level task execution. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx

pnpm dlx create-turbo@latest -e with-rsbuild-module-federation
yarn dlx create-turbo@latest -e with-rsbuild-module-federation
npx create-turbo@latest -e with-rsbuild-module-federation
bunx create-turbo@latest -e with-rsbuild-module-federation

Practical Next Steps

Begin with the Rsbuild example if you are evaluating a new stack, because it gives you a known-good Turborepo shape before application-specific deployment assumptions enter the project. If you are adding Rsbuild to an existing monorepo, generate the app inside the workspace, install any internal packages with the repository package manager, run the install step, and align package scripts with root task names. Then add package-level task configuration only for real execution or caching differences. For composed frontends, set the Rsbuild server base on child apps and compare the standard example with the module federation example. Sources: apps/docs/content/docs/guides/frameworks/rsbuild.mdx, apps/docs/content/docs/guides/frameworks/framework-bindings.mdx

Ask a question...