fix(ivy): ngcc - recognize synthesized constructors

[JoostK]

ngcc needs to be able to identify synthesized constructors in order to let ngtsc create a base factory call, instead of assuming a no-args constructor.

This is important for Material, e.g. the following code (source):

export class MatTable<T> extends CdkTable<T> {
  /** Overrides the sticky CSS class set by the `CdkTable`. */
  protected stickyCssClass = 'mat-table-sticky';
}

is compiled to ES2015 (source):

class MatTable extends CdkTable {
    constructor() {
        super(...arguments);
        /**
         * Overrides the sticky CSS class set by the `CdkTable`.
         */
        this.stickyCssClass = 'mat-table-sticky';
    }
}

and downleveled to ES5 (source):

var MatTable = /** @class */ (function (_super) {
    __extends(MatTable, _super);
    function MatTable() {
        var _this = _super !== null && _super.apply(this, arguments) || this;
        /**
         * Overrides the sticky CSS class set by the `CdkTable`.
         */
        _this.stickyCssClass = 'mat-table-sticky';
        return _this;
    }
    MatTable.decorators = [/* ... */];
    return MatTable;
}(CdkTable));

Currently, ngcc reports the MatTable class to have a no-args constructor, resulting in a factory function that doesn't inject the dependencies of CdkTable.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.io application / infrastructure changes
• Other... Please describe:

[JoostK]

@petebacondarwin I have updated the code with some more documentation and added ES2015 support. For the ES2015 tests I choose to include them in the existing file, whereas I split out the ES5 constructor tests into a separate file. I am now wondering which is better 🤔

Regarding the tests, I feel it's a bit overkill to add tests that verify all possible mismatches in AST structure. How do you feel about that? Are the current tests sufficient or do you see some additional ones that should be added?

[petebacondarwin]

LGTM

[petebacondarwin]

I would be tempted to keep the tests in the files rather than splitting them out. It makes the git history a bit simpler.

[JoostK]

I added an integration test in b29dd5c only to find that ES5 didn't actually work :-)

I added fixup commit 2c9df97 in which hasBaseClass is specialized for ES5, that should fix the issue.

The test still fails though, as we're now emitting const into an ES5 file. This is mostly due to the same issue as we recently had with emitting ! into JavaScript files. There's a few options to solve this:

1. Always translate declarations as var instead of const.
2. Let the transformer accept a mode such that it can decide how to emit a declaration.
3. Avoid the Angular to TS translation and emit from the Angular AST.

EDIT: Discussed offline that emitting const in ES5 should not cause any issues.

[mhevery]

http://test/OCL:228414744:BASE:228414779:1546991340803:5880acf7

[kara]

@JoostK Can you rebase this one? (ping me when you're ready and I'll merge)

[JoostK]

@kara I can't at the moment, I'm on holiday this week. Will rebase coming weekend if none of you have beaten me to it (the conflict is trivial to resolve, only a Js docblock was added)

[petebacondarwin]

I have rebased on master. This has triggered the code-owners approval process.

[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.}