Reproduces as reported, and the cause is exactly what I expected to find.

1. when ngtsc compiles the library, the cycle detector rejects the import from RecursiveItemComponent for the directiveDefs of RecursiveListComponent as it would create a cycle.

2. instead, ngtsc deopts to a side-effectful ɵɵsetComponentScope call next to MyLibModule.

3. because the module is in a library, it gets built by CLI with a package.json which says sideEffects: false

4. Terser dutifully strips the ɵɵsetComponentScope call when processing the library code

5. One of the components is missing its directiveDefs at runtime.

I can think of only one real solution here: ngtsc needs to be modified to be okay with cycles externally, since external tooling can handle them. We would need to generate wrapped directiveDef arrays for both components in this case, as we don’t know in what order these files will be imported. This is pretty tricky to keep track of, and also has an impact on incremental build since the addition of a cycle could require the emit of new files.

A workaround is to set sideEffects: true in the library package.json, which tells the optimizer not to remove top-level calls (among other things).

We have encountered this recently.

We have moved a part of our app to a library and as our app is built with Ivy, we consumed Ivy library version as well. It was very much confusing experience when in prod mode the library turned out broken where it was working flawlessly in dev mode. The worst thing that there are zero clues how to debug and where to dig - fail happens silently and verbose mode is not much of a help - the output of terser is very cryptic - it’s not clear at all what is being shaken off and why. After hours of googling was lucky to found this issue…

With that said, I believe --verbose mode should provide meaningful information about things being removed from the build. That would make it much easier to troubleshoot issues like this. I have already raised this once in another issue (start reading from https://github.com/angular/angular/issues/37102#issuecomment-628782822), but that seems didn’t go anywhere.

Also, I agree this issue shouldn’t be marked as low frequency and second priority - this is pretty much a fundamental issue with libraries Ivy builds and Ivy builds are promoted as main way to build libraries going forward.

If you have 2 components in the library, A and B, and you include B in A’s template and use a static method of A in B (or exported funtion/class/anything), the same problem occurs.

// my-lib.component.ts
@Component({
  selector: 'lib-my-lib',
  template: `
      <lib-other></lib-other>
  `,
  styles: []
})
export class MyLibComponent{}
export function getSomething() {
  return `something`;
}

// other.component.ts
@Component({
  selector: 'lib-other',
  template: `
    <div>{{someInput}}</div>
  `,
  styles: []
})
export class OtherComponent {
  someInput = getSomething();
}

Reproduction is here: https://github.com/darress/angular9_lib_bugs/tree/import_recursion

This is maybe a more minimal reproduction of the problem.

The same workaround ("sideEffects": true) works here too.

I agree that freq1: low is probably not appropriate - and in fact is not featuring in our triage of issues anymore anyway. The key label is P2 which I think accurately captures this issue:

The issue is important to a large percentage of users, with a workaround. Issues that are significantly ugly or painful (especially first-use or install-time issues). Issues with workarounds that would otherwise be P0 or P1.

Hi @elesueur to build your library with view engine your tsconfig needs enableIvy: false in the angularCompilerOptions, see here: https://angular.io/guide/ivy#opting-out-of-ivy-in-version-9

Hi @alxhub we meet this problem too https://github.com/ng-packagr/ng-packagr/issues/1576 I think the freq label should not be low, and it is very hard to figure what happened after encountering this bug

@Phil147 indeed, this is an instance of the same problem.

What is really interesting if you build against the library source code and not the dist folder, this problem does not happen.

This is because the application is built with sideEffects: true by default 😃

Thank you @alxhub for the workaround, we can go full Ivy now!

Also @darress, thank you for the small and useful reproduction, it allowed me to verify what I thought was happening very easily.