Основні команди NestJS CLI
Основні команди NestJS CLI
🎯 Мета лекції
- Опанувати роботу з інструментом командного рядка NestJS CLI (Command Line Interface)
- Навчитися автоматично генерувати компоненти через команду
nest generate - Вивчити скорочення команд для прискорення розробки
- Засвоїти генерацію модулів, контролерів, сервісів та повних ресурсів
- Практикувати використання опцій генерації (
--no-spec,--flat,--dry-run) - Зрозуміти структуру шляхів для організації коду у вкладені модулі
- Ознайомитися з командами запуску застосунку у різних режимах
- Навчитися перевіряти структуру проєкту перед генерацією через dry-run
🔑 Ключові терміни
- CLI (Command Line Interface): інтерфейс командного рядка для автоматизації задач
- Code Generation (генерація коду): автоматичне створення файлів та шаблонів
- Schematic: шаблон генерації, що визначає структуру та вміст файлів
- Dry Run: симуляція виконання команди без реальних змін у файловій системі
- Resource: повний набір компонентів для REST API (module, controller, service, DTO)
- Flat Structure (плоска структура): розміщення файлів без створення вкладеної папки
- Watch Mode (режим спостереження): автоматична перекомпіляція при зміні коду
Інтерфейс командного рядка NestJS CLI
NestJS CLI (Command Line Interface) — це потужний інструмент командного рядка, що суттєво прискорює розробку через автоматизацію рутинних задач: створення проєктів, генерацію компонентів, запуск серверу розробки та збірку застосунку для продакшн. CLI забезпечує консистентність (consistency) структури коду, дотримання найкращих практик та економію часу розробника.
Філософія інструменту
На відміну від ручного створення файлів, NestJS CLI використовує schematic-підхід (schematics) — попередньо визначені шаблони, що генерують код з правильною структурою, іменуванням та взаємозв'язками між компонентами:
Ручне створення (без CLI):
// ❌ Потрібно вручну створити 4+ файли
// users/users.controller.ts
// users/users.service.ts
// users/users.module.ts
// users/dto/create-user.dto.ts
// users/users.controller.spec.ts
// users/users.service.spec.ts
// Потім вручну імпортувати контролер у модуль
// Потім зареєструвати модуль у app.module.ts
// Ризик помилок у іменуванні та імпортах
Генерація через CLI:
# ✅ Одна команда створює всі файли та реєстрацію
nest generate resource users
Встановлення та перевірка CLI
NestJS CLI встановлюється глобально через npm:
npm install -g @nestjs/cli
yarn global add @nestjs/cli
pnpm add -g @nestjs/cli
Перевірка встановлення:
nest не знайдена після встановлення, переконайтеся, що шлях до глобальних пакетів npm додано до змінної оточення PATH. У macOS/Linux перевірте ~/.bashrc або ~/.zshrc, у Windows — налаштування системних змінних.Команда nest generate
nest generate (скорочення: nest g) — основна команда для створення компонентів застосунку. Вона приймає схематик (schematic) — тип компоненту та його ім'я, після чого генерує необхідні файли та оновлює існуючі модулі.
Базовий синтаксис
nest generate <schematic> <name> [options]
# Скорочений варіант:
nest g <schematic> <name> [options]
Параметри:
- schematic — тип компоненту (
module,controller,service, тощо) - name — ім'я компоненту у форматі kebab-case або camelCase
- options — додаткові прапорці для налаштування генерації
Доступні схематики
| Схематик | Скорочення | Призначення | Створені файли |
|---|---|---|---|
| module | mo | Модуль | <name>.module.ts |
| controller | co | Контролер | <name>.controller.ts, <name>.controller.spec.ts |
| service | s | Сервіс (провайдер) | <name>.service.ts, <name>.service.spec.ts |
| class | cl | TypeScript клас | <name>.ts |
| interface | itf | TypeScript інтерфейс | <name>.interface.ts |
| guard | gu | Guard (охоронець) | <name>.guard.ts, <name>.guard.spec.ts |
| interceptor | itc | Interceptor (перехоплювач) | <name>.interceptor.ts |
| middleware | mi | Middleware (мідлвар) | <name>.middleware.ts |
| pipe | pi | Pipe (труба валідації) | <name>.pipe.ts |
| filter | f | Exception Filter | <name>.filter.ts |
| decorator | d | Кастомний декоратор | <name>.decorator.ts |
| gateway | ga | WebSocket Gateway | <name>.gateway.ts |
| resource | res | Повний CRUD ресурс | module, controller, service, DTO |
nest g mo usersзамістьnest g module usersnest g co usersзамістьnest g controller usersnest g s usersзамістьnest g service users
Структура шляхів
Ім'я компоненту може містити шлях для організації у вкладені папки:
# Створення у кореневій папці src/
nest g module users
# → src/users/users.module.ts
# Створення у вкладеній папці
nest g controller users/admin
# → src/users/admin/admin.controller.ts
# Створення у глибокій ієрархії
nest g service api/v1/users
# → src/api/v1/users/users.service.ts
Генерація модуля
Модуль (module) — основний будівельний блок архітектури NestJS, що об'єднує пов'язані компоненти (контролери, сервіси) у логічну групу.
Команда генерації
nest generate module <name>
# Скорочення:
nest g mo <name>
Приклад: створення модуля users
Створені файли:
app.module.ts та додає його до масиву imports. Це забезпечує негайну інтеграцію модуля у застосунок без ручних правок.Генерація модуля у вкладеній папці
# Модуль у папці features/
nest g mo features/auth
# → src/features/auth/auth.module.ts
# Модуль у папці api/v1/
nest g mo api/v1/products
# → src/api/v1/products/products.module.ts
Результуюча структура:
src/
├── app.module.ts
├── features/
│ └── auth/
│ └── auth.module.ts
└── api/
└── v1/
└── products/
└── products.module.ts
Генерація контролера
Контролер (controller) обробляє вхідні HTTP-запити та визначає маршрути (routes) застосунку.
Команда генерації
nest generate controller <name>
# Скорочення:
nest g co <name>
Приклад: створення контролера users
Створені файли:
Ключові спостереження:
- Автоматична реєстрація: Контролер додано до масиву
controllersуUsersModule - Тестовий файл: CLI створює базовий unit-тест (
*.spec.ts) для контролера - Іменування маршруту: Декоратор
@Controller('users')автоматично отримує префікс з імені
# Модуль ще не існує
nest g co products
# → CLI створить products.module.ts та зареєструє контролер
Генерація вкладеного контролера
# Контролер у підпапці admin
nest g co users/admin
# → src/users/admin/admin.controller.ts
# → Реєструється у UsersModule (якщо існує)
Генерація сервісу
Сервіс (service) містить бізнес-логіку застосунку та інкапсулює доступ до даних. Сервіси є провайдерами (providers), що ін'єктуються через Dependency Injection.
Команда генерації
nest generate service <name>
# Скорочення:
nest g s <name>
Приклад: створення сервісу users
Створені файли:
Ключові спостереження:
- Декоратор @Injectable(): Позначає клас як провайдера для DI контейнера
- Реєстрація у providers: Сервіс додано до масиву
providersмодуля - Готовність до ін'єкції: Тепер сервіс можна ін'єктувати у контролер або інші сервіси
Використання згенерованого сервісу
Після генерації сервіс можна одразу ін'єктувати у контролер:
// src/users/users.controller.ts
import { Controller, Get } from '@nestjs/common';
import { UsersService } from './users.service';
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}
@Get()
findAll() {
return this.usersService.findAll();
}
}
// src/users/users.service.ts
import { Injectable } from '@nestjs/common';
@Injectable()
export class UsersService {
private users = [
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' },
];
findAll() {
return this.users;
}
}
Генерація повного ресурсу (Resource)
nest generate resource — найпотужніша команда CLI, що створює повний набір компонентів для REST API або GraphQL: модуль, контролер, сервіс, DTO (Data Transfer Objects), та entity класи. Це ідеальна команда для швидкого прототипування або створення нових функціональних блоків.
Команда генерації
nest generate resource <name>
# Скорочення:
nest g res <name>
Інтерактивний режим
При виконанні команди CLI запитає кілька питань для налаштування:
Структура згенерованого ресурсу
Що генерує nest g resource
| Файл | Призначення |
|---|---|
| products.controller.ts | REST контролер з повним CRUD (Create, Read, Update, Delete) |
| products.service.ts | Сервіс з методами-заглушками для бізнес-логіки |
| products.module.ts | Модуль, що об'єднує контролер та сервіс |
| dto/create-product.dto.ts | DTO для створення продукту (POST запит) |
| dto/update-product.dto.ts | DTO для оновлення продукту (PATCH запит) |
| entities/product.entity.ts | Entity клас для представлення моделі даних |
| products.controller.spec.ts | Unit-тест контролера |
| products.service.spec.ts | Unit-тест сервісу |
Переваги nest g resource
- Швидкість: Створення повного CRUD за 30 секунд
- Консистентність: Однакова структура у всіх модулях
- Best practices: Правильна архітектура "з коробки"
- Тести: Базові unit-тести вже включені
Генерація класів та інтерфейсів
Для створення DTO, entity або допоміжних класів використовуються команди nest g class та nest g interface.
Генерація класу (DTO)
nest generate class <path>
# Скорочення:
nest g cl <path>
Приклад: створення DTO для користувача:
Створений файл:
// src/users/dto/create-user.dto.ts
export class CreateUserDto {}
Заповнення DTO валідацією:
import { IsEmail, IsString, MinLength, MaxLength } from 'class-validator';
export class CreateUserDto {
@IsEmail()
email: string;
@IsString()
@MinLength(2)
@MaxLength(50)
name: string;
@IsString()
@MinLength(8)
password: string;
}
Генерація інтерфейсу
nest generate interface <path>
# Скорочення:
nest g itf <path>
Приклад: створення інтерфейсу для конфігурації:
Створений файл:
// src/config/database-config.interface.ts
export interface DatabaseConfig {}
Заповнення інтерфейсу:
export interface DatabaseConfig {
host: string;
port: number;
username: string;
password: string;
database: string;
}
- Клас — існує у runtime, підтримує декоратори валідації (для DTO)
- Інтерфейс — лише compile-time типізація, видаляється після компіляції
Опції генерації
NestJS CLI підтримує кілька корисних опцій для налаштування процесу генерації.
--no-spec: Без тестових файлів
За замовчуванням CLI генерує unit-тести (*.spec.ts) для кожного компонента. Щоб вимкнути це:
nest g service users --no-spec
# → Створює лише users.service.ts (без users.service.spec.ts)
nest g controller products --no-spec
# → Створює лише products.controller.ts
Коли використовувати:
- Прототипування — тести будуть написані пізніше
- E2E-first підхід — unit-тести не потрібні
- Legacy проєкти без тестового покриття
--no-spec лише для швидкого прототипування.--flat: Плоска структура без папки
За замовчуванням CLI створює вкладену папку для компонента. Опція --flat розміщує файли у поточній директорії:
# Без --flat (стандартна поведінка):
nest g service logger
# → src/logger/logger.service.ts
# → src/logger/logger.service.spec.ts
# З --flat:
nest g service logger --flat
# → src/logger.service.ts (без папки logger/)
# → src/logger.service.spec.ts
Коли використовувати:
- Утилітарні сервіси у папці
common/ - Декоратори та pipes у папці
shared/ - Хелпери у папці
utils/
--dry-run: Симуляція без змін
Опція --dry-run (скорочення: -d) виконує симуляцію генерації без реального створення файлів. Корисно для перевірки, що буде створено:
Коли використовувати:
- Перевірка структури перед реальною генерацією
- Навчання команд CLI
- Перевірка конфліктів імен файлів
--skip-import: Без реєстрації у модулі
Опція --skip-import створює компонент, але не додає його до жодного модуля:
nest g service auth --skip-import
# → Створює auth.service.ts, але не оновлює auth.module.ts
Коли використовувати:
- Ручна реєстрація через custom providers
- Динамічні модулі
- Експериментальний код
Комбінування опцій
Опції можна комбінувати:
# Сервіс без тестів, плоска структура, dry-run
nest g service logger --no-spec --flat --dry-run
# Контролер без тестів та реєстрації
nest g controller admin --no-spec --skip-import
# Ресурс без тестів у вкладеній папці
nest g resource api/v1/users --no-spec
Команди запуску застосунку
Після генерації компонентів застосунок потрібно запустити. NestJS CLI надає кілька команд для різних режимів роботи.
nest start: Базовий запуск
nest start
Компілює TypeScript у JavaScript та запускає застосунок один раз. Після зупинки сервера потрібно перезапустити вручну.
Коли використовувати:
- Тестування після збірки
- Запуск у Docker-контейнері
- Відлагодження проблем компіляції
nest start:dev: Режим розробки з watch
npm run start:dev
# або
nest start --watch
Запускає застосунок у watch mode — автоматично перекомпілює та перезапускає сервер при зміні файлів.
Переваги:
- Миттєвий feedback loop — зміни застосовуються за 1-2 секунди
- Не потрібно вручну перезапускати сервер
- Ідеально для активної розробки
start:dev як основну команду під час розробки. Це економить години часу протягом проєкту.nest start:debug: Режим відлагодження
npm run start:debug
Запускає застосунок з підтримкою Node.js debugger на порті 9229. Можна підключитися через Chrome DevTools або VS Code Debugger.
Налаштування VS Code для відлагодження:
// .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "attach",
"name": "Attach NestJS Debugger",
"port": 9229,
"restart": true,
"stopOnEntry": false,
"protocol": "inspector"
}
]
}
Використання:
- Запустіть
npm run start:debug - Встановіть breakpoints у VS Code
- Натисніть F5 або "Run → Start Debugging"
- Виконайте HTTP-запит — виконання зупиниться на breakpoint
nest build: Компіляція для продакшн
nest build
Компілює TypeScript у оптимізований JavaScript код для production:
Результат:
dist/
├── main.js
├── main.js.map
├── app.module.js
├── users/
│ ├── users.controller.js
│ ├── users.service.js
│ └── users.module.js
└── ... (всі файли застосунку)
Запуск продакшн-версії:
node dist/main.js
npm run start:prod: Продакшн-режим
npm run start:prod
Виконує nest build та запускає скомпільований код:
# Еквівалентно:
nest build && node dist/main
Коли використовувати:
- Фінальне тестування перед деплоєм
- Запуск у production-середовищі (сервер, Docker)
- Вимірювання продуктивності
Порівняльна таблиця команд запуску
| Команда | Компіляція | Watch | Debugger | Використання |
|---|---|---|---|---|
| nest start | ✅ Один раз | ❌ | ❌ | Разове тестування |
| start:dev | ✅ При змінах | ✅ | ❌ | Активна розробка |
| start:debug | ✅ При змінах | ✅ | ✅ | Відлагодження проблем |
| nest build | ✅ Production | ❌ | ❌ | Збірка для деплою |
| start:prod | ✅ Production | ❌ | ❌ | Запуск на сервері |
Додаткові корисні команди
Окрім генерації та запуску, CLI надає команди для інформації про проєкт та налаштування.
nest info: Інформація про проєкт
nest info
Виводить версії встановлених пакетів NestJS та залежностей:
Коли використовувати:
- Діагностика проблем з версіями пакетів
- Створення bug reports
- Перевірка сумісності залежностей
nest new: Створення нового проєкту
nest new <project-name>
Створює новий NestJS проєкт з нуля:
Створена структура:
my-app/
├── src/
│ ├── app.controller.ts
│ ├── app.controller.spec.ts
│ ├── app.module.ts
│ ├── app.service.ts
│ ├── app.service.spec.ts
│ └── main.ts
├── test/
│ ├── app.e2e-spec.ts
│ └── jest-e2e.json
├── node_modules/
├── .eslintrc.js
├── .prettierrc
├── nest-cli.json
├── package.json
├── tsconfig.json
└── tsconfig.build.json
Практичні сценарії використання CLI
Розглянемо реальні робочі процеси розробки з використанням NestJS CLI.
Сценарій 1: Створення нового модуля з нуля
Задача: Додати функціональність управління постами у блозі.
Крок 1: Створення структури модуля
# Генерація модуля
nest g module posts
# → src/posts/posts.module.ts
# Генерація контролера
nest g controller posts --no-spec
# → src/posts/posts.controller.ts
# Генерація сервісу
nest g service posts --no-spec
# → src/posts/posts.service.ts
Крок 2: Створення DTO та Entity
# DTO для створення поста
nest g class posts/dto/create-post.dto --no-spec
# → src/posts/dto/create-post.dto.ts
# DTO для оновлення поста
nest g class posts/dto/update-post.dto --no-spec
# → src/posts/dto/update-post.dto.ts
# Entity для моделі поста
nest g class posts/entities/post.entity --no-spec
# → src/posts/entities/post.entity.ts
Результуюча структура:
src/posts/
├── dto/
│ ├── create-post.dto.ts
│ └── update-post.dto.ts
├── entities/
│ └── post.entity.ts
├── posts.controller.ts
├── posts.module.ts
└── posts.service.ts
Альтернатива — одна команда:
# Замість 6 команд вище:
nest g resource posts --no-spec
# → Створює всю структуру автоматично!
Сценарій 2: Модульна архітектура з вкладеністю
Задача: Створити структуру для API v1 з users та products.
# Створення базових модулів
nest g module api/v1/users --no-spec
nest g module api/v1/products --no-spec
# Контролери для кожного модуля
nest g controller api/v1/users --no-spec
nest g controller api/v1/products --no-spec
# Сервіси
nest g service api/v1/users --no-spec
nest g service api/v1/products --no-spec
Результуюча структура:
src/
├── api/
│ └── v1/
│ ├── users/
│ │ ├── users.controller.ts
│ │ ├── users.module.ts
│ │ └── users.service.ts
│ └── products/
│ ├── products.controller.ts
│ ├── products.module.ts
│ └── products.service.ts
└── app.module.ts
Налаштування префіксу маршруту у main.ts:
// src/main.ts
async function bootstrap() {
const app = await NestFactory.create(AppModule);
// Глобальний префікс для всіх маршрутів
app.setGlobalPrefix('api/v1');
await app.listen(3000);
}
bootstrap();
// Тепер маршрути доступні за адресою:
// GET /api/v1/users
// GET /api/v1/products
Сценарій 3: Спільні утиліти та декоратори
Задача: Створити спільні компоненти для використання у різних модулях.
# Створення папки common
mkdir src/common
# Генерація кастомного декоратора
nest g decorator common/decorators/current-user --flat --no-spec
# → src/common/decorators/current-user.decorator.ts
# Генерація pipe для валідації
nest g pipe common/pipes/parse-int --flat --no-spec
# → src/common/pipes/parse-int.pipe.ts
# Генерація guard для автентифікації
nest g guard common/guards/auth --flat --no-spec
# → src/common/guards/auth.guard.ts
# Генерація interceptor для логування
nest g interceptor common/interceptors/logging --flat --no-spec
# → src/common/interceptors/logging.interceptor.ts
Результуюча структура:
src/common/
├── decorators/
│ └── current-user.decorator.ts
├── pipes/
│ └── parse-int.pipe.ts
├── guards/
│ └── auth.guard.ts
└── interceptors/
└── logging.interceptor.ts
--flat створює файли без вкладених папок, що зручно для організації спільних компонентів у структуровані директорії.Сценарій 4: Тестування перед генерацією (dry-run)
Задача: Перевірити, що буде згенеровано без реальних змін.
# Перевірка структури ресурсу
nest g resource notifications --dry-run
# Перевірка вкладеної структури
nest g controller admin/users --dry-run
# Перевірка з опціями
nest g service analytics --no-spec --flat --dry-run
Переваги dry-run:
- Перевірка імен файлів перед створенням
- Виявлення конфліктів з існуючими файлами
- Планування структури проєкту
Best Practices: ефективна робота з CLI
Рекомендації для максимальної продуктивності при роботі з NestJS CLI.
Правило 1. Використовуйте скорочення команд
❌ Повільно:
nest generate module users
nest generate controller users
nest generate service users
✅ Швидко:
nest g mo users
nest g co users
nest g s users
Або ще краще — одна команда:
nest g resource users
Правило 2. Плануйте структуру заздалегідь
Погана практика — генерація у корені:
nest g mo users
nest g mo products
nest g mo orders
# → src/users/, src/products/, src/orders/ (плоска структура)
Хороша практика — групування за функціоналом:
# Групування за доменом
nest g mo features/auth
nest g mo features/billing
nest g mo features/analytics
# Або версіонування API
nest g mo api/v1/users
nest g mo api/v1/products
Правило 3. Створюйте алиаси для часто використовуваних команд
Додайте до ~/.zshrc або ~/.bashrc:
# NestJS aliases
alias ngs="nest g service"
alias ngc="nest g controller"
alias ngm="nest g module"
alias ngr="nest g resource"
alias ngcl="nest g class"
# З опціями
alias ngs-ns="nest g service --no-spec"
alias ngc-ns="nest g controller --no-spec"
Використання:
ngs users # → nest g service users
ngc-ns products # → nest g controller products --no-spec
ngr orders # → nest g resource orders
Правило 4. Використовуйте --no-spec для прототипування
Під час розробки MVP:
# Швидке прототипування без тестів
nest g resource prototype --no-spec
# Тести додаються пізніше, коли логіка стабілізується
У стабільних проєктах:
# Завжди з тестами
nest g resource users
# → Створює *.spec.ts файли
--no-spec для експериментального коду та первинного прототипування. Як тільки функціональність стабілізується — напишіть тести вручну або регенеруйте компоненти з тестами.Правило 5. Перевіряйте структуру через dry-run
Перед масовою генерацією:
# Спочатку симуляція
nest g resource api/v2/users --dry-run
# Переконалися, що структура правильна
nest g resource api/v2/users
Правило 6. Організуйте спільні компоненти у common/
Структура для спільних компонентів:
# Декоратори
nest g decorator common/decorators/roles --flat --no-spec
# Guards
nest g guard common/guards/roles --flat --no-spec
# Interceptors
nest g interceptor common/interceptors/transform --flat --no-spec
# Pipes
nest g pipe common/pipes/validation --flat --no-spec
# Filters
nest g filter common/filters/http-exception --flat --no-spec
Результуюча структура:
src/common/
├── decorators/
│ ├── roles.decorator.ts
│ └── current-user.decorator.ts
├── guards/
│ ├── roles.guard.ts
│ └── auth.guard.ts
├── interceptors/
│ ├── transform.interceptor.ts
│ └── logging.interceptor.ts
├── pipes/
│ └── validation.pipe.ts
└── filters/
└── http-exception.filter.ts
Налаштування CLI через nest-cli.json
Файл nest-cli.json дозволяє налаштувати поведінку CLI для всього проєкту.
Базова конфігурація
{
"$schema": "https://json.schemastore.org/nest-cli",
"collection": "@nestjs/schematics",
"sourceRoot": "src",
"compilerOptions": {
"deleteOutDir": true,
"webpack": true,
"tsConfigPath": "tsconfig.build.json"
},
"generateOptions": {
"spec": false,
"flat": false
}
}
Опції generateOptions
| Опція | Тип | За замовчуванням | Опис |
|---|---|---|---|
| spec | boolean | true | Генерувати тестові файли *.spec.ts |
| flat | boolean | false | Створювати файли без вкладеної папки |
| specFileSuffix | string | "spec" | Суфікс для тестових файлів |
Приклад: вимкнення тестів глобально
{
"generateOptions": {
"spec": false
}
}
Тепер всі команди nest g будуть працювати як з прапорцем --no-spec:
nest g service users
# → Створює лише users.service.ts (без users.service.spec.ts)
nest-cli.json застосовуються глобально для всього проєкту. Для одноразової зміни поведінки краще використовувати опції командного рядка (--no-spec, --flat).Резюме команд CLI
🚀 Генерація компонентів
nest g module <name>— модульnest g controller <name>— контролерnest g service <name>— сервісnest g resource <name>— повний CRUD ресурсnest g class <name>— клас (DTO, Entity)nest g interface <name>— інтерфейс
⚙️ Опції генерації
--no-spec— без тестових файлів--flat— без вкладеної папки--dry-run— симуляція без змін--skip-import— без реєстрації у модулі
▶️ Запуск застосунку
nest start— одноразовий запускnpm run start:dev— watch mode (розробка)npm run start:debug— з debuggernest build— збірка для productionnpm run start:prod— запуск production
📋 Інформація
nest --version— версія CLInest info— інформація про проєктnest --help— список всіх командnest g --help— допомога по генерації
Порівняльна таблиця: ручна vs CLI генерація
| Аспект | Ручне створення | NestJS CLI |
|---|---|---|
| Швидкість | 10-15 хвилин | 30 секунд |
| Помилки | Високий ризик | Мінімальний |
| Консистентність | Залежить від розробника | Гарантована |
| Імпорти | Вручну | Автоматично |
| Реєстрація | Вручну | Автоматично |
| Тести | Вручну | Включені |
| Структура | Довільна | Best practices |
Ні, NestJS CLI не має команди для видалення компонентів. Видалення потрібно робити вручну:
# Видалення модуля вручну
rm -rf src/users/
# Також потрібно вручну видалити імпорт з app.module.ts
# import { UsersModule } from './users/users.module'; ← Видалити
Рекомендація: Використовуйте --dry-run перед генерацією, щоб переконатися у правильності структури.
CLI автоматично знаходить відповідний модуль за шляхом:
# Модуль users вже існує
nest g module users
# Контролер буде додано до UsersModule автоматично
nest g controller users
# → Оновлює src/users/users.module.ts
# Сервіс теж додається до UsersModule
nest g service users
# → Оновлює src/users/users.module.ts
CLI аналізує шлях (users/) та реєструє компонент у модулі з такою ж назвою.
Використовуйте --skip-import та зареєструйте вручну:
# Генерація без автоматичної реєстрації
nest g service special-logger --skip-import
# Потім вручно додайте у потрібний модуль
Або просто перемістіть файли та оновіть імпорти:
// src/logging/logging.module.ts
import { SpecialLoggerService } from '../special-logger/special-logger.service';
@Module({
providers: [SpecialLoggerService],
exports: [SpecialLoggerService],
})
export class LoggingModule {}
Так, через custom schematics. Можна створити власну колекцію схематиків:
# Встановлення schematics CLI
npm install -g @angular-devkit/schematics-cli
# Створення власної колекції
schematics blank --name=my-schematics
# Налаштування nest-cli.json
{
"collection": "./my-schematics/src/collection.json"
}
Проте для більшості проєктів достатньо стандартних шаблонів NestJS.
nest g resource для швидкого створення функціональних модулів, --dry-run для перевірки структури та start:dev як основний режим розробки. Це економить години часу та забезпечує консистентну архітектуру проєкту.