# Обфускація застосунку Nuxt

@afterpack/nuxt — це модуль Nuxt 3, який реєструє @afterpack/vite у конфігурації Vite вашого Nuxt.

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

Nuxt 3 збирає бандл через Vite, а AfterPack інтегрується на рівні **бандлера**, тож `@afterpack/nuxt` — це тонкий модуль Nuxt: він викликає `addVitePlugin`, щоб зареєструвати [`@afterpack/vite`](https://www.afterpack.dev/uk/docs/frameworks/vite) у конфігурації Vite вашого Nuxt, і клієнтський бандл обфускується в `generateBundle` Vite, ще до запису збірки.

Проєкти на Nuxt 2 збираються через webpack. Для них натомість використовуйте [`@afterpack/webpack`](https://www.afterpack.dev/uk/docs/frameworks/webpack).

## Встановлення

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

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

Параметри задаються під ключем конфігурації `afterpack`.

## Збірка

`nuxt generate` (статика) або `nuxt build` (SSR) тепер видає обфускований результат. `nuxt dev` не зачіпається, бо плагін працює лише на `generateBundle` Vite. Для кожного середовища Vite (клієнтського і серверного) реєструється окремий екземпляр плагіна `@afterpack/vite`, і кожен обфускує власний бандл, перш ніж Vite його запише.

### Статика чи сервер

- **Статика / попередній рендеринг** (`nuxt generate`): обфускується попередньо відрендерений клієнтський бандл у `.output/public/_nuxt/`. Це рекомендована форма для випуску захищеного клієнтського коду.
- **Сервер (SSR)**: клієнтський бандл обфускується так само; серверний бандл Nitro — це ваш власний артефакт розгортання.

Закріпіть [`seed: "git"`](https://www.afterpack.dev/uk/docs/config#seed), коли хочете, щоб клієнтські частини одного релізу збиралися з одного сіду, або коли збірка має бути відтворюваною до байта (влучання в кеш, еталонні знімки). [Збірки та CI](https://www.afterpack.dev/uk/docs/builds) описують цей компроміс. Nuxt також генерує новий `buildId` для кожної збірки.

## Перевірка

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

Записує об'єднану [Protection Map](https://www.afterpack.dev/uk/docs/protection-map) у `.afterpack/protectionMap.html`, внесений у gitignore. Побічний ефект із source map і правила поводження з ними такі самі, як у [`@afterpack/vite`](https://www.afterpack.dev/uk/docs/frameworks/vite#verify).

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

Щоб перевірити розгортання, запустіть `npx afterpack@latest verify .output/public` перед завантаженням. Nitro копіює туди захищену клієнтську збірку, а [`verify`](https://www.afterpack.dev/uk/docs/cli#afterpack-verify-dir) перевіряє копію за квитанцією захисту збірки і називає кожен змінений файл.

## Параметри

Будь-який [ключ конфігурації](https://www.afterpack.dev/uk/docs/config) можна передати під ключем конфігурації `afterpack`; він без змін пересилається в [`@afterpack/vite`](https://www.afterpack.dev/uk/docs/frameworks/vite#options), наприклад `afterpack: { preset: "hard", complexity: 40 }`. Псевдонім типу `AfterpackNuxtOptions` дорівнює `AfterpackViteOptions`.

## Директиви

Директиви — це можливість тарифу [Pro](https://www.afterpack.dev/uk/docs/pro). У [збірці Free](https://www.afterpack.dev/uk/docs/directives#free-builds) директива, яка посилює захист, зупиняє збірку з помилкою `DIAG_PRO_DIRECTIVE_REQUIRES_KEY`.

Маркер `/* @afterpack … */` усередині файлу `.vue` не зчитується. Натомість розмістіть директиву у звичайному модулі `.ts`/`.js` (composable, файл у `utils/`), який імпортує компонент.

## Далі

- [Фреймворки](https://www.afterpack.dev/uk/docs/frameworks): повна матриця.
- [Vite](https://www.afterpack.dev/uk/docs/frameworks/vite): плагін, який виконує основну роботу.
- [Vue](https://www.afterpack.dev/uk/docs/frameworks/vue): звичайний застосунок на Vue 3 + Vite.
- [Protection Map](https://www.afterpack.dev/uk/docs/protection-map): як читати звіт.
- [Збірки та CI](https://www.afterpack.dev/uk/docs/builds): сіди, dev проти prod, просування тих самих байтів.