Есть ли правило линтинга (или проверка компилятора), которое может включать ошибку для неявных типов из внешнего модуля? - PullRequest
Новая
       78

Есть ли правило линтинга (или проверка компилятора), которое может включать ошибку для неявных типов из внешнего модуля?

2 голосов
/ 10 июля 2020

Проблема:

Я работаю над проектом Angular, в котором используется структура nrwl/nx monorepo. Проблема, которую мы наблюдаем, может быть воспроизведена следующим образом:

libs/module1/shared-class.ts

export class SharedClass {}

libs/module2/service.ts

import { SharedClass } from '@project/module1';
import { Subject, Observable } from 'rxjs';
export class Service {
  private readonly subject = new Subject<SharedClass>();
  readonly sharedClassObservable: Observable<SharedClass> = this.subject.asObservable();
}

libs/module2/my-component.component.ts

import { Service } from './service';
export class MyComponent {
  readonly sharedClass$ = this.service.sharedClassObservable;
  constructor(private readonly service: Service) {}
}

Проблема в том, что в MyComponent sharedClass$ есть предполагаемый тип, и во время упаковки он превращается в нечто похожее на это в файле .d.ts: 

export declare class MyComponent {
  readonly sharedClass$: Observable<import("../../../../../dist/libs/module1").SharedClass>
}

Исправление это легко; вы просто явно объявляете тип sharedClass$. Но ошибка действительно тупая (в основном просто говорится, что нельзя импортировать из '../../../../../dist/xxx).

Итак, я пытался найти какое-то правило tslint или ng-packagr, которое я мог бы добавить чтобы убедиться, что такого рода проблема обнаружена на более ранних этапах, а не только в конце нашего процесса сборки, когда мы пытаемся запустить созданный пакет (фактическая сборка пакета работает нормально, поэтому понятно, что большинство разработчиков считают, что это работает аналогично их локальному экземпляру разработчика), но его сложно найти. Кто-нибудь знает, как это поймать?

...