lssssssssssl

npm run lint --fix

Никак не получить. Советую всю эту логику пересмотреть, чтобы такого делать не пришлось.

Можете, конечно, в CryptoColumnTransformer получить конфиг в виде private readonly config = new ConfigService(), но это такое себе решение.
Лучше просто обратитесь к process.env. в CryptColumnTransformer

Это статические методы класса модуля.

Отличие зависит от реализации самих модулей. Но в общем смысле: forRoot используется для главной настройки и вызывается единожды, чаще всего в appModule, а forFeature для каких-то дополнительных надстроек и может вызываться много раз в разных модулях.

Например, на примере MoongooseModule для mongodb, forRoot используется для принятия конфига базы данных единожды, а forFeature много раз в разных модулях для подключения сущностей

Задайте item тип ServiceDocument

Перебирать массив сервисов не нужно, просто уберите .populate('services') и используйте serviceModel.deleteMany(), который принимает массив айдишников для удаления множества документов.

Нужно внедрить ServiceService в конструктор ServiceCategoryService private serviceService: ServiceService,
после чего обращаться кthis.serviceService

Создаем 100к однотипных объектов и отправляем
Принимаем и выводим длину пришедшего массива

Смотрим вывод в терминале: все корректно пришло и без ошибок.


Можете свой код показать или хотя бы часть?

Нет. В токене заложен срок жизни - изменение времени понесет за собой изменение самого токена

Допустимо.

Но вообще зависит от логики вашего приложения.
Если хотите использовать JwtService в других модулях, тогда вам нужно зарегистрировать JwtModule в одном из своих модулей и экспотировать его.
Смысл этого в том, чтобы один раз в приложении вызвать метод registerAsync() и переиспользовать этот же модуль с этим выполненным методом в других модулях.

Но лично я не советую вам делать экспорт конкретно из AuthModule, потому что AuthModule наоборот должен импортировать другие модули в себя, а не быть импортом для кого-то.

С PassportModule аналогично. Но лично я всегда храню его в AuthModule и никуда не экспортирую, и больше нигде не использую.
Экспортировать JwtStrategy нет смысла, так как единственное место, где вы её используете, это в JwtAuthGuard.

Подведя итог: Можно экспотировать, но чаще всего не нужно( Я за 2 года не встретил ещё такой надобности )

Локальная стратегия нужна только при аутентификации(Можно и без неё обойтись, написав ручками то же самое).
В остальных случаях jwt стратегия.
Регистрация не должна иметь guard, ежели пользователя ещё нет в бд и проверять его не на что.

Кастомный декоратор напишите для user, и сделайте для него dto.
https://docs.nestjs.com/custom-decorators

Можете сделать dto и использовать в нём @Transform для преобразования к числу

export class ExampleDto {
  @Transform((exp) => Number(exp.value))
  @ApiProperty() // or @ApiModelPropertyOptional()
  @IsNumber()
  @IsNotEmpty() // or @IsOptional()
  exp: number;
}

@Delete(':userId')
  remove(@Param('userId') userId: string) {
    return this.userService.remove(userId);
  }

1. Делаете ng build в angular проекте
   
2. Кладёте результат билда( папку dist ) в свой проект на nestjs в папку client(Или любое другое имя на ваше предпочтение в корне проекта, кроме папки dist, ежели она обновляется после каждого build nestjs)
   
3. Настраиваете nestjs для работы со статикой https://docs.nestjs.com/recipes/serve-static
   
4. Делаете build проекта на nestjs
   
5. В package.json проверяете наличие команды "start:prod": "node dist/main"
   
6. Запускаете команду, смотрите всё ли корректно работает(Видна ли статика)
   
7. Делаете деплой полученного nestjs приложения, как обычное nestjs приложение. Про ангуляр можно уже забыть, так как он превратился в простой js код в папке client. Считайте, что он стал полноправной частью nestjs кода
   

Папку client в .gitignore или любой другой игнор добавлять, конечно же, не нужно
Проблем с корсой не будет в этом случае