ngcc - use inner/outer class names as appropriate

[petebacondarwin]

// FW-1651

In the @ngx-formly/material library, there are directives that inherit from other classes. In ES5 format this results in class declarations that have the following form:

var Child = /** @class */ (function (_super) {
    __extends(Child_Inner, _super);
    function Child_Inner() {...}
    return Child_Inner;
}(Parent));

But then ngcc is adding definitions into the class as follows:

var Child = /** @class */ (function (_super) {
    __extends(Child_Inner, _super);
    function Child_Inner() {...}
    Child.ɵfac = ...;
    Child.ɵdir = ...;
    return Child_Inner;
}(Parent));

Note that the new definitions are referring to Child which is the outer class identifier.

Unfortunately this Child identifier has not been initialised at the time the definitions are attached, so we get a Reference error.

One approach was to move the definitions outside of the IIFE as follows:

var Child = /** @class */ (function (_super) {
    __extends(Child_Inner, _super);
    function Child_Inner() {...}
    return Child_Inner;
}(Parent));
Child.ɵfac = ...;
Child.ɵdir = ...;

This works for this case, but fails if the decorator definition contains references to identifiers that are only defined inside the IIFE. For example:

var BrowserModule = /** @class */ (function () {
    function BrowserModule(parentModule) {...}
    BrowserModule_1 = BrowserModule;
    var BrowserModule_1;
    BrowserModule = BrowserModule_1 = __decorate([
      __param(0, Optional()),
      __param(0, SkipSelf()),
      __param(0, Inject(BrowserModule_1)),
      __metadata("design:paramtypes", [Object])
    ], BrowserModule);
    return BrowserModule;
}());
BrowserModule.ɵmod = ɵngcc0.ɵɵdefineNgModule({ type: BrowserModule });
BrowserModule.ɵinj = ɵngcc0.ɵɵdefineInjector({
  factory: function BrowserModule_Factory(t) {
    return new (t || BrowserModule)(ɵngcc0.ɵɵinject(BrowserModule_1, 12));
  },
  providers: BROWSER_MODULE_PROVIDERS,
  imports: [CommonModule, ApplicationModule]
});

Here you can see that the ɵɵdefineInjector() call references BrowserModule_1 which is only defined within the IIFE.

Also this is not correct because it stops the class from being tree shaken, since the IIFE is the unit of tree shaking.

So the proper solution is to teach ngcc/ngtsc which identifiers to use when generating ES5 definitions.

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[gkalpak]

👍

Inconsistent "quotation" marks in the first commit message's subject line:
refactor(ivy): split 'type' into 'type', 'internalType' and `adjacentType` --> refactor(ivy): split `type` into `type`, `internalType` and `adjacentType`

[gkalpak]

Could this method be called with a TS ClassDeclaration (e.g. from a .d.ts file)?

[petebacondarwin]

I was debating this with myself. I left it as throwing and ran all the ngcc tests and it never threw.

The fact that this never returns null means that we can't try calling the super first. So we possibly could try calling it if the declaration is not in ES5 format.

I think the point is (at least as things stand right now) that ngtsc only ever calls this method when it is working on the source, not typings.

So at the moment I feel confident leaving it as it is.

[petebacondarwin]

Thanks @gkalpak

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[alxhub]

Presubmit
No Ivy presubmit needed - ngcc change

[ngbot]

I see that you just added the PR action: merge label, but the following checks are still failing:
     status "google3" is failing

If you want your PR to be merged, it has to pass all the CI checks.

If you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}