Install and Setup

During a Nuxt build, @the-i18n-kit/nuxt writes down the layer graph and locale table Nuxt resolved so the CLI reads them instead of reconstructing them from outside.

1. Install and Register

pnpm add -D @the-i18n-kit/nuxt

export default defineNuxtConfig({
  modules: ['@nuxtjs/i18n', '@the-i18n-kit/nuxt'],
})

It declares compatibility with Nuxt >=3.0.0 and is a dev dependency: nothing it writes reaches the browser. Module order does not matter.

@nuxtjs/i18n has to be installed and configured. With no i18n block on the resolved Nuxt options the module logs that it published nothing and stops — the build still succeeds and the CLI behaves as it does without the module.

2. Remove the Keys It Derives

Delete locales, localeDirs and defaultLocale from i18n-kit.config.ts or .i18n-mcp.json. The module derives all three, and declaring them by hand now fails the build. Everything else in those files stays: the module carries no kit policy, which is what makes policy apply in a checkout that has never built. See where configuration lives.

3. Build Once and Check

npx nuxt prepare
cat .nuxt/i18n-kit.json

A successful run logs how much it published. Then run any command that resolves the project:

the-i18n-cli status

When the artifact is used, the CLI says so and names the version that wrote it. When it is not, it warns with the reason and loads the app through Nuxt instead — or, when the artifact is simply absent, loads the app with no message.

In a Monorepo

Register the module in every Nuxt app. Each publishes its own artifact describing its own layer graph, and the CLI merges the apps as it does today. An app without the module is loaded through Nuxt, so you can adopt it one app at a time.

Next

• The Artifact and Options — what the file carries, the two module options, and every case where the CLI ignores it.
• Layer-Aware Missing Keys — the ESLint blocks you can add to withNuxt() alongside this module. The module itself writes no ESLint config.