Хотя да, статический анализ теоретически

это уже дело тайпскрипта

Камиль на Holy.js сказал, что пока в nest точно такого не будет

Раскрой, пожалуйста, тему токенов поподробней, эта сущность где объявлена? Откуда токены импортятся, из nest? Не получится ли тогда что бизнес логика завязалась на nest?

Не, для токенов отдельный модуль
Он никак от Неста не зависит

хотелось бы писать так чтоб nest можно было оторвать, выкинуть и заменить

токены — это чать IoC неста. Конечно, в бизнес-логику протягивать IoC не нужно

для получения зависимостей у тебя есть aplication services там ты забираешь из IoC нужные зависимости и закидываешь уже в бизнес-логику. Готово, фреймворк не проник в бизнес-логику )

тоесть в итогде резолвишь сам ручками “по бедному” :)

ну не совсем, ты забираешь красиво, но дальше закидываешь ручками в конструктор, да. Но все фабрики остаются внутри IoC

https://docs.nestjs.com/fundamentals/custom-providers#non-class-based-provider-tokens

@Injectable()
export class CatsRepository {
  constructor(@Inject('CONNECTION') connection: Connection) {}
}

The @Inject() decorator is imported from @nestjs/common package.

конечно,

@Inject

это часть неста, в бизнес-логике ему не место

как и

@Injectable

@Injectable()
export class CatsRepository {
  constructor(@Inject('CONNECTION') connection: Connection) {}
}

Это не токены же

Всмысле токен здесь 'coonection'

Никто не мешает вынести его

токен — это метка, сам по себе он бесполезен

а получится ли писать бизнес логику с использованием инфраструктуры nestjs (DI не ручками) но без проникания ее в код?
например если вместо интерфейсов и токенов будем принимать в ctor abstract class

cats-repository.ts:

export class CatsRepository extends AbstractCatsRepository {
  constructor(connection: AbstractConnection) {}
}


app.module.ts:

@Module({
  providers: [
    CatsRepository,
    {
      provide: AbstractConnection,
      useValue: ConcreteConnection,
    }
  ],
})
export class AppModule {}

примерно так мы пишем код на C# только у нас есть interfaces (в runtime) всесто abstract classes

Ну он будет только в конструкторе. При необходимости убираете декоратор и все. Код независим, можно в другой проджект вставить. Либо написать обертку, и свой кастомный декоратор, если код может быть переиспользован в другом месте где будет другой IoC контейнер, или вовсе не будет.

в тесты инфрастуктура всё равно проникнет