# Obfuscate a Nuxt app

@afterpack/nuxt is a Nuxt 3 module that registers @afterpack/vite on Nuxt's Vite config.

Source: https://www.afterpack.dev/docs/frameworks/nuxt

Nuxt 3 bundles with Vite, and AfterPack integrates at the **bundler** level, so `@afterpack/nuxt` is a thin Nuxt module: it calls `addVitePlugin` to register [`@afterpack/vite`](https://www.afterpack.dev/docs/frameworks/vite) on Nuxt's Vite config, and the client bundle is obfuscated in Vite's `generateBundle`, before the build is written.

Nuxt 2 projects build with webpack. Use [`@afterpack/webpack`](https://www.afterpack.dev/docs/frameworks/webpack) there instead.

## Install

```bash
npm install -D @afterpack/nuxt
```

```ts
// nuxt.config.ts
export default defineNuxtConfig({
  modules: ["@afterpack/nuxt"],
  afterpack: {
    seed: "git",
  },
});
```

Options live under the `afterpack` config key.

## Build

`nuxt generate` (static) or `nuxt build` (SSR) now emits obfuscated output. `nuxt dev` is untouched, because the plugin only runs on Vite's `generateBundle`. A fresh `@afterpack/vite` plugin instance is registered per Vite environment (client and server), and each one obfuscates its own bundle before Vite writes it.

### Static vs. server

- **Static / prerendered** (`nuxt generate`): the prerendered client bundle in `.output/public/_nuxt/` is obfuscated. This is the recommended shape for shipping protected client code.
- **Server (SSR)**: the client bundle is obfuscated the same way; the Nitro server bundle is your own deployment artifact.

Pin [`seed: "git"`](https://www.afterpack.dev/docs/config#seed) when you want the client legs of one release built from the same seed, or when a build has to be byte-reproducible (cache hits, golden snapshots). [Builds & CI](https://www.afterpack.dev/docs/builds) covers the trade. Nuxt also generates a fresh `buildId` per build.

## Verify

```ts
export default defineNuxtConfig({
  modules: ["@afterpack/nuxt"],
  afterpack: { protectionMap: { enabled: true } },
});
```

Writes the combined [Protection Map](https://www.afterpack.dev/docs/protection-map) to the gitignored `.afterpack/protectionMap.html`. The source-map side effect and the handling rules are [`@afterpack/vite`](https://www.afterpack.dev/docs/frameworks/vite#verify)'s.

*(live Protection Map demo embed — see https://www.afterpack.dev/protection-map-demo.html)*

## Options

Every [configuration key](https://www.afterpack.dev/docs/config) can be passed under the `afterpack` config key, forwarded verbatim to [`@afterpack/vite`](https://www.afterpack.dev/docs/frameworks/vite#options), for example `afterpack: { preset: "hard", complexity: 40 }`. The type alias `AfterpackNuxtOptions` is `AfterpackViteOptions`.

## Directives

A `/* @afterpack … */` marker inside a `.vue` file is not captured. Put the directive in a plain `.ts`/`.js` module (a composable, a `utils/` file) that the component imports instead.

## Next

- [Frameworks](https://www.afterpack.dev/docs/frameworks): the full matrix.
- [Vite](https://www.afterpack.dev/docs/frameworks/vite): the plugin doing the actual work.
- [Vue](https://www.afterpack.dev/docs/frameworks/vue): a plain Vue 3 + Vite app.
- [Protection Map](https://www.afterpack.dev/docs/protection-map): reading the report.
- [Builds & CI](https://www.afterpack.dev/docs/builds): seeds, dev-vs-prod, promoting the same bytes.