False detection of potential dependency

Type of Issue

[x] Bug Report
[ ] Feature Request

Description

The source analyser will detect internal, dependant package via this logic:

https://github.com/ng-packagr/ng-packagr/blob/c2efc42591ea8f2581cb7c8d3ea16a6b9cfa526e/src/lib/ng-package/entry-point/analyse-sources.transform.ts#L62-L71

This matching logic is very simple, assuming every module resolved that starts with the current package name is a secondary, internal package. This is not always the case.

There are several scenarios that can fail this.

For example, I have a package @scope/A and an internal package @scope/A/B

@scope/A does import from @scope/B thus it will get picked up by the logic above, at some point.
However, if I reference an internal part in @scope/B, like @scope/B/internal/path it will get caught and since it’s not actually a library it will throw an exception

ERROR: Entry point @scope/B/internal/path which is required by @scope/A doesn't exists.

Now, we might say that referencing @scope/B/internal/path might not be valid and we better reference it in a relative way, which is OK i guess.

However, i’m not physically referencing it, in my scenario i’m just augmenting a type in @scope/B which is located at @scope/B/internal/path.

declare module '@scope/B/internal/path' {
  interface MyAugmentedInterface {
    str: string;
  }
}

This one goes through the resolution pipeline, although type only, and so throws an exception.

In general the logic to detected internal packages is very inclusive and I didn’t find an option that allows setting excluded paths or some way of modifiying the behaviour.

I don’t want to augment via relative paths because the output structure might not fit the source file structure. So the location of the augmented .d.ts in the output dist should not be relative but absolute. When absolute it will work in development as well as packaged

Regardless, personally I think that this method of detecting child packages is very “generous”. Maybe some conventions should be in place. For example, the directory of the child path must have a package.json with at least the “name” property of the package included. This looks like a reasonable convention to me.

Version Information

ng-packagr:            12.0.0
@angular/compiler:     12.0.0
rollup:                2.48.0
typescript:            4.2.4

[alan-agius4]

@JoMen6 & @dschwank, I have a fix for your case https://github.com/ng-packagr/ng-packagr/pull/2003 which will be released later on today.

[JoMen6]

@alan-agius4 It works, thank you very much 🙏