fix(common): strict type checking for ngtemplateoutlet

[tomalaforge]

When we create a context to inject inside our ngTemplateOutlet, the context was declare as Object, therefore, there are no compilation error.

Now if we add a context, we get error at compile type.

BREAKING CHANGE: If the 'ngTemplateOutletContext' is different from the context, it will result in a compile-time error.

Before the change, the following template was compiling:

interface MyContext {
  $implicit: string;
}

@component({
  standalone: true,
  imports: [NgTemplateOutlet],
  selector: 'person',
  template: `
    <ng-container
      *ngTemplateOutlet="
        myTemplateRef;
        context: { $implicit: 'test', xxx: 'xxx' }
      "></ng-container>
  `,
})
export class PersonComponent {
  myTemplateRef!: TemplateRef<MyContext>;
}

However, it does not compile now because the 'xxx' property does not exist in 'MyContext', resulting in the error: 'Type '{ $implicit: string; xxx: string; }' is not assignable to type 'MyContext'.'

The solution is either:

• add the 'xxx' property to 'MyContext' with the correct type or
• add '$any(...)' inside the template to make the error disappear. However, adding '$any(...)' does not correct the error but only preserves the previous behavior of the code.

fix #43510

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[tomalaforge]

If someone can help me understand why the pipeline is failiing at the 'install java' step, I would be able to correct it. This will be greatly appreciated.
Thank you

[atscott]

Hi @tomalaforge - In general, I think this change looks correct and it's a great improvement.

That said, it's absolutely a breaking change since the type is more restrictive. There were several thousand build failures internally because of this (root causes are much lower since most failures are shared components).

At the very least, this will need the BREAKING CHANGE: ... footer to describe what's changed and what to do when there's a new failure. The easiest thing to do, and the approach I've landed on for the moment, is just adding $any to wrap the context in the template when there are failures. This obviously doesn't "fix" the type but it does make the failure go away without any behavioral changes to the code. You can probably describe this and some other possible solutions to common failures in the breaking change note and/or commit message.

[atscott]

Quick update: There were only about a total of ~30 templates needing updates internally so this is certainly feasible to land. Adding my approval now and will mark for merge when internal code has been migrated.

reviewed-for: public-api, fw-common

[atscott]

passing TGP

[atscott]

This PR was merged into the repository by commit d47fef7.

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