Проблемы DI в NestJS при импорте из разных путей и их решение

Импорт одного и того же сервиса из разных путей (например, dist/... вместо src/...) в NestJS нарушает работу DI, так как TypeScript создаёт уникальные ссылки на класс при каждом новом импорте. Это приводит к тому, что токен внедрения перестаёт соответствовать токену провайдера, даже если логика класса идентична. Решение требует единообразного использования путей и строгой настройки псевдонимов в монорепозиториях. Ключевые практики включают контроль через линтинг и единый источник импорта для предотвращения конфликтов.

Содержание

• Почему импорт из разных путей ломает DI в NestJS
• Проблемы в монорепозиториях и с псевдонимами путей
• Как настроить сборку и линтинг для предотвращения ошибок
• Лучшие практики для соответствия токена внедрения и провайдера

Почему импорт из разных путей ломает DI в NestJS

NestJS использует токены внедрения для сопоставления провайдеров с зависимостями. По умолчанию токеном выступает сам класс. Но если вы импортируете этот класс из разных путей (например, из src/services в development и из dist/services в production), TypeScript создаст разные ссылки на один и тот же класс. Для DI-контейнера это будут два уникальных токена, даже если логика идентична.

Представьте ситуацию:

// src/module.ts
import { UserService } from './services'; // Путь 1

// dist/module.js
import { UserService } from '../dist/services'; // Путь 2

NestJS видит два разных класса, поэтому при запросе UserService он не найдёт соответствующего провайдера. Это не ошибка кода, а особенность работы модульной системы TypeScript и механизма DI.

Но почему это критично именно в NestJS? Потому что фреймворк полагается на строгую идентичность ссылок, а не на сравнение имён или структуры классов. Даже незначительное отличие в пути импорта приведёт к ошибке Nest can't resolve dependencies of the ....

Проблемы в монорепозиториях и с псевдонимами путей

В монорепозиториях (Lerna, Nx, Turborepo) проблема усугубляется из-за перекрёстных зависимостей между пакетами. Например, при использовании псевдонимов вроде @myapp/core:

// tsconfig.json
{
 "compilerOptions": {
 "paths": {
 "@myapp/core": ["libs/core/src"]
 }
 }
}

Если один пакет импортирует сервис через @myapp/core, а другой — напрямую из libs/core/src, DI перестанет работать.

Кейс из практики:
В проекте на Nx мы столкнулись с ошибкой, когда auth-module использовал @myapp/data для импорта DatabaseService, а user-module — путь libs/data/src. Решение потребовало:

1. Унификации всех импортов через псевдонимы.
2. Добавления правила в tsconfig.base.json для единообразного разрешения путей.
3. Проверки через линтинг, чтобы запретить импорты из src в production-коде.

Это не просто «техническая мелочь» — такие ошибки могут привести к непредсказуемому поведению в production, особенно если сборка использует разные пути для development и production.

Как настроить сборку и линтинг для предотвращения ошибок

1. Настройка сборки

Для монорепозиториев критично единообразное разрешение путей на всех этапах:

• В tsconfig.json укажите baseUrl и paths для всех пакетов.
• Используйте tsconfig.build.json с настройкой noEmit: false, чтобы избежать конфликтов между development и production.

Пример конфига:

{
 "extends": "./tsconfig.json",
 "compilerOptions": {
 "outDir": "./dist",
 "baseUrl": "./",
 "paths": {
 "@myapp/*": ["libs/*"]
 }
 },
 "exclude": ["node_modules", "dist", "test"]
}

2. Правила линтинга

Добавьте в .eslintrc.js правило, запрещающее импорты из src в production-коде:

rules: {
 'no-restricted-imports': [
 'error',
 {
 patterns: ['**/src/*', '!**/src/index.ts'],
 message: 'Используйте псевдонимы (например, @myapp/core) вместо прямых путей к src.'
 }
 ]
}

Это предотвратит ситуацию, когда разработчик случайно импортирует сервис через src в production-модуле.

3. Проверка токенов

Для отладки добавьте в main.ts проверку:

const token = UserService;
console.log('Токен внедрения:', token.name);

Если в разных модулях выводится разное имя (например, UserService vs UserService_1), значит, пути импорта конфликтуют.

Лучшие практики для соответствия токена внедрения и провайдера

1. Используйте строковые токены для критичных случаев

Если конфликты путей неизбежны (например, в кросс-репозиториевых сценариях), явно укажите строковый токен:

// В провайдере
{
 provide: 'USER_SERVICE',
 useClass: UserService
}

// При внедрении
constructor(@Inject('USER_SERVICE') private userService: UserService) {}

Это обходной путь, но его стоит применять только в крайних случаях — он снижает типобезопасность.

2. Единый точка входа для импорта

Создайте index.ts в каждой библиотеке:

// libs/core/src/index.ts
export * from './services/user.service';

Теперь все импорты должны идти через @myapp/core, а не напрямую из src. Это гарантирует, что TypeScript будет работать с одной ссылкой на класс.

3. Тестирование на уровне сборки

Добавьте в CI-процесс проверку, которая:

• Собирает проект в production-режиме.
• Запускает unit-тесты, проверяющие корректность DI.
• Использует ts-morph для анализа путей импорта.

Пример теста:

import { Module } from '@nestjs/common';
import { UserService } from '@myapp/core';

@Module({
 providers: [UserService],
 exports: [UserService],
})
export class TestModule {}

// Проверка, что токен совпадает
expect(TestModule.providers[0].provide).toBe(UserService);

4. Документируйте правила

Создайте CONTRIBUTING.md с четкими инструкциями:

«Все импорты из внутренних библиотек должны использовать псевдонимы (например, @myapp/core). Прямые пути к src запрещены в production-коде. Нарушение приведет к ошибке DI.»

Источники

1. NestJS Dependency Injection — Официальная документация по работе с DI в NestJS: https://docs.nestjs.com/providers
2. Path Mapping in TypeScript — Руководство по настройке путей импорта в tsconfig: https://www.typescriptlang.org/docs/handbook/module-resolution.html
3. Monorepo Best Practices — Статья о решении проблем с DI в монорепозиториях: https://nx.dev/tutorials/monorepo-nestjs

Заключение

Импорт сервисов из разных путей ломает DI в NestJS из-за уникальности ссылок на классы в TypeScript. Чтобы избежать этой проблемы:

• Всегда используйте псевдонимы вместо прямых путей к src.
• Настройте линтинг для блокировки некорректных импортов.
• Тестируйте сборку на соответствие токенов внедрения.
• Для критичных сценариев применяйте строковые токены, но помните о потере типобезопасности.

Лучшая практика — единая точка входа через index.ts и строгая политика импортов. Это гарантирует, что DI будет работать стабильно как в development, так и в production. А если вы уже столкнулись с ошибкой — проверьте, не дублируется ли класс в разных путях. Часто решение проще, чем кажется: один правильный импорт — и DI снова в строю.