feat(compiler-cli): support host directives for local compilation mode

[pmvald]

At the moment local compilation breaks for host directives because the current logic relies on global static analysis. This change creates a local version by cutting the diagnostics and copying the directive identifier as it is to the generated code without attempting to statically resolve it.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/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:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[devversion]

LGTM, but @crisbeto built host directives and might have some thoughts too

[devversion]

This still feels non-ideal to me. I wonder, do you think we can do something like this here?

if (localCompilation && !isReference(current.directive)) {
  // skip intentional
} else if (!isReference) {
  throw new Error("Unexpected")
}

[pmvald]

Did something similar by using the narrower type HostDirectiveMetaForGlobalMode. Ideally we should use this type in all type checking utilities.

[pmvald]

Ah no, didn't work. Ended up having to change lot of things. For for now I just throw exception if the host dir meta is not the right type. Having the condition "localCompilation" requires some plumbing of the compilation mode into several classes in the /typecheck/... which makes a footprint rather large for this PR. So I think having a robust solution needs a separate PR and possibly these steps:

1. We need to ban the whole code path in /typecheck/... for local compilation. this can be done by checking the compilstion mode in the entrypoints
2. Using the type HostDirectiveMetaForGlobalMode for TypeCheckableDirectiveMeta.hostDirectives instead of HostDirectiveMeta (tried to do that in this PR but triggered a large cascade changes all over the place)

[devversion]

Why did having a branded expression type not work? e.g.

class LocalCompilationExpression {
  __localCompilationBrand = true;
  constructor(public expression: o.Expression) {}
}

that could then be passed around in HostDirectiveMeta and used for reliable checking and type narrowing. Your current solution is better than before, but I think this would be even safer? maybe a follow-up consideration yes

[pmvald]

Yeah, make sense. We do have this situation (i.e., | Expression for local compilation case) in several other places for meta data interfaces. We can probably migrate them all in a separate PR to use a LocalCompilationExpression (instead of Expression) and make a contract that any meta with a LocalCompilationExpression type value should be coming from local compilation source, etc. (is my understanding correct?)

[devversion]

Correct, and we can then "filter these" values and throw more safely for "Impossible states"

[pmvald]

Gotcha. I add this to my TODO list. For now shall we mark this PR for merge?

[devversion]

Sure!

[crisbeto]

LGTM once Paul's feedback is addressed.

[pkozlowski-opensource]

This PR was merged into the repository by commit 3e13840.

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