Nuxt

Purpose and Scope

This page explains how to add and operate a Nuxt application inside a Turborepo workspace. Nuxt is presented in the repository docs as an open source framework for intuitive and powerful web development, while Turborepo provides the monorepo task orchestration around it. The practical reader problem is usually not how to run Nuxt in isolation, but how to place a Nuxt app under apps/, connect it to shared internal packages, and make sure its build, dev, and other scripts participate in the same root turbo.json task graph as the rest of the repository.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx, apps/docs/content/docs/guides/frameworks/index.mdx

The Nuxt guide belongs to the broader framework-guides section, where the docs state that Turborepo works with any framework and then provide focused pages for common frontend frameworks. That framing matters because there is no Nuxt-specific Turborepo runtime adapter described here. Instead, Nuxt remains responsible for application behavior, Nuxi remains responsible for scaffolding Nuxt projects, and Turborepo coordinates package-manager workspaces, task execution, cacheable outputs, and package-level task overrides. Treat the Nuxt integration as a workspace and task-configuration workflow rather than a framework replacement.

Sources: apps/docs/content/docs/guides/frameworks/index.mdx, apps/docs/content/docs/guides/frameworks/meta.json

Relevant Source Files

• apps/docs/content/docs/guides/frameworks/nuxt.mdx - Primary Nuxt integration guide, including quickstart commands, Nuxi scaffolding, internal package installation examples, task customization notes, and microfrontend base configuration.
• apps/docs/content/docs/guides/frameworks/framework-bindings.mdx - Shared guidance for framework-specific bindings in internal library packages through peer dependencies and package export paths.
• apps/docs/content/docs/guides/frameworks/index.mdx - Framework guide overview that positions Nuxt alongside other framework integrations and states that Turborepo works with any framework.
• apps/docs/content/docs/guides/frameworks/meta.json - Navigation metadata showing nuxt as one of the framework-guide pages and placing framework-bindings in the same section.
• apps/docs/content/docs/guides/frameworks/nextjs.mdx - Neighboring framework guide with the same add-app, internal-package, package-configuration, and microfrontend structure used to understand shared guide conventions.
• apps/docs/content/docs/guides/frameworks/rsbuild.mdx - Neighboring framework guide that reinforces the shared example-based quickstart pattern and framework-specific microfrontend asset-base guidance.

Quickstart with the Official Example

For the fastest path, start from the with-vue-nuxt example through create-turbo. The Nuxt guide gives equivalent commands for pnpm, Yarn, npm, and Bun, all using the same example selector. This creates a repository already arranged for Turborepo, so you can inspect how the workspace packages, app scripts, and root task definitions fit together before adapting the structure to your own project. This is the recommended learning path when you want a working monorepo first and a custom architecture second.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

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

After creating the example, look for the same three layers you would maintain in a production workspace: the Nuxt application package, any shared packages consumed by the app, and the root Turborepo configuration that names tasks. The docs do not require a special Nuxt-only command to make Turborepo aware of the application. Turborepo discovers packages through the workspace layout and then runs scripts that are present in package manifests. If the generated application has scripts that do not match your repository’s task names, update the app’s package.json scripts or adjust task configuration accordingly.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

Adding Nuxt to an Existing Monorepo

When you already have a Turborepo repository, use Nuxi, Nuxt’s CLI, from the repository root to create the new application in a package directory such as apps/my-app. Running the scaffolder from the root keeps the new app inside the workspace convention used by the docs. The generated package still belongs to Nuxt, so it may include Nuxt-oriented defaults, but the next Turborepo step is to align package scripts and dependencies with the rest of the monorepo.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

pnpm dlx nuxi@latest init apps/my-app
yarn dlx nuxi@latest init apps/my-app
npx nuxi@latest init apps/my-app
bunx nuxi@latest init apps/my-app

Once the app exists, run your package manager’s install command so the workspace lockfile and package links are updated. This install step is explicitly called out because adding a package directory and editing package.json are not enough for every package manager to resolve workspace dependencies. You should also review the generated scripts field. For example, if the root turbo.json defines build and dev tasks, the Nuxt package should expose scripts with those names when you expect turbo run build or turbo run dev to include it.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

Integrating Internal Packages and Framework Bindings

A common reason to use Nuxt in a Turborepo monorepo is to share UI, configuration, or domain packages with other applications. The Nuxt guide shows adding an internal package such as @repo/ui to ./apps/my-app/package.json. The exact version specifier depends on the package manager: pnpm and Bun examples use workspace:*, while Yarn and npm examples use *. The important Turborepo concept is that the Nuxt app consumes the internal package as a normal dependency, allowing package relationships to participate in workspace installation and task dependency ordering.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

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

If a shared library needs to expose Nuxt-specific or framework-specific behavior, use the framework-bindings pattern from the same docs section. Framework bindings are library entrypoints that intentionally rely on framework APIs. The guide explains this pattern with Next.js examples, but it explicitly says the concept applies to any framework or dependency. The two source-level mechanisms are peerDependencies, which let the consuming app provide the framework version, and exports, which split framework-specific entrypoints so bundlers and consumers can import the intended binding.

Sources: apps/docs/content/docs/guides/frameworks/framework-bindings.mdx

Task Configuration and Package Overrides

By default, the Nuxt application uses tasks defined in the root turbo.json. In practice, this means the root configuration is the first place to look when deciding whether Nuxt builds are cacheable, which outputs should be restored, and which upstream tasks must complete first. The Nuxt page points readers to Package Configurations when an application needs different task behavior. Use that path when one Nuxt app has a different output directory, a special development script, or a package-specific task dependency that should not apply globally.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

This same root-first then package-specific model appears in neighboring framework guides for Next.js and Rsbuild, which helps confirm that the docs are teaching a consistent Turborepo pattern rather than a Nuxt exception. Add the framework application with its official scaffolder, install internal packages through the workspace package manager, rely on root tasks for the default behavior, and use package-level configuration when the framework application needs its own task shape. That sequence keeps framework details local while preserving monorepo-wide task orchestration.

Sources: apps/docs/content/docs/guides/frameworks/nextjs.mdx, apps/docs/content/docs/guides/frameworks/rsbuild.mdx

Microfrontends and Asset Routing

The Nuxt guide includes one Nuxt-specific microfrontend note: when using Nuxt with Turborepo’s microfrontends, set the Vite base property for child applications. The purpose is asset routing. Without an application-specific base, assets such as images and CSS can be requested from the wrong path when multiple applications are composed under different routes. In the documented example, a child application mounted at /admin sets base: "/admin", making the generated asset URLs line up with the application route.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx

import { defineConfig } from "vite";
 
export default defineConfig({
  base: "/admin",
});

This requirement is framework-specific in its configuration field but shared in intent across the framework guides. Next.js uses basePath, Rsbuild uses server.base, and Nuxt’s guide uses Vite’s base. That comparison is useful when a repository has multiple frontend frameworks: Turborepo can coordinate the tasks for all of them, but each framework still owns how it prefixes routes and static assets. Keep those settings close to each child app and test the mounted path used by your microfrontend host.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx, apps/docs/content/docs/guides/frameworks/nextjs.mdx, apps/docs/content/docs/guides/frameworks/rsbuild.mdx

Implementation Checklist

Start with the official with-vue-nuxt example if you are evaluating the stack, or run Nuxi under apps/my-app if you are adding Nuxt to an existing workspace. Add internal packages through the app’s dependencies, run the package-manager install command, and align the app’s scripts with the root tasks you expect Turborepo to run. If the Nuxt app needs different task behavior, add a package-level configuration rather than overfitting the root task for every package. For shared libraries with framework-aware APIs, use peer dependencies and explicit export paths to keep bindings intentional.

Sources: apps/docs/content/docs/guides/frameworks/nuxt.mdx, apps/docs/content/docs/guides/frameworks/framework-bindings.mdx

Next, read the package-configuration reference when task behavior diverges, the internal-packages concept when sharing code with @repo/* packages, and the microfrontends guide before composing Nuxt under a route prefix. If your repository also includes Next.js, Vite, or Rsbuild, compare their framework guides for the same workflow shape and the framework-specific asset-base setting each one requires.