Is there a linting rule (or compiler check) that can be enabled to error on implicit types from an external module?

Viewed 55

The problem:

I'm working on an Angular project that's using a nrwl/nx monorepo structure. The issue that we're seeing can be replicated like this

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) {}
}

The problem is that in MyComponent sharedClass$ has an inferred type and during packaging this is turned in to something that looks like this in the .d.ts file:

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

The fix is easy; you simply explicitly declare the type of sharedClass$. But the error is really obtuse (it basically just says it can't import from '../../../../../dist/xxx).

So I've been trying to find some kind of tslint or ng-packagr rule I could add to make sure that this kind of issue is caught at earlier stages rather than only at the end of our build process where we attempt to run the created package (the actual building of the package works just fine, so understandably most devs believe it to work similarly to their local dev instance), but it's proving difficult to search for. Does anyone know of a way to catch this?

0 Answers
Related