Commit Graph

6 Commits

Author SHA1 Message Date
Paul Gschwendtner 12bad6576d fix(compiler-cli): libraries compiled with v16.1+ breaking with Angular framework v16.0.x (#50714)
If a library is compiling with Angular v16.1.0, the library will break
for users that are still on Angular v16.0.x. This happens because the
`DirectiveDeclaration` or `ComponentDeclaration` types are not expecting
an extra field for `signals` metadata. This field was only added to the
generic types in `16.1.0`- so compilations fail with errors like this:

```
Error: node_modules/@angular/material/icon/index.d.ts:204:18 -
  error TS2707: Generic type 'ɵɵComponentDeclaration' requires between 7 and 9 type arguments.
```

To fix this, we quickly roll back the code for inserting this metadata
field. That way, libraries remain compatible with all v16.x framework
versions.

We continue to include the `signals` metadata if `signals: true` is set.
This is not public API anyway right now- so cannot happen- but imagine
we expose some signal APIs in e.g. 16.2.x, then we'd need this metadata
and can reasonably expect signal-component library users to use a more
recent framework core version.

PR Close #50714
2023-06-14 16:27:59 +02:00
Andrew Scott 5214df4958 refactor(compiler-cli): Add signals to internal directive metadata (#49981)
This commit adds the `signals: boolean` property to the internal
directive/component metadata. This does not add it to the public API
yet, as the feature has no internal support other than compiler
detection.

PR Close #49981
2023-04-25 15:39:18 -07:00
Kristiyan Kostadinov 54ceed53e2 refactor(compiler): add support for host directives (#46868)
This is the compile-time implementation of the `hostDirectives` feature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the new `ɵɵHostDirectivesFeature` feature whenever a directive has a `hostDirectives` field. Afterwards `ɵɵHostDirectivesFeature` will patch a new function onto the directive definition that will be invoked during directive matching.

For example, if we take the following definition:

```ts
@Directive({
  hostDirectives: [HostA, {directive: HostB, inputs: ['input: alias']}]
})
class MyDir {}
```

Will compile to:

```js
MyDir.ɵdir = ɵɵdefineComponent({
  features: [ɵɵHostDirectivesFeature([HostA, {
    directive: HostB,
    inputs: {
      input: "alias"
    }
  }])]
});
```

The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template.

Relates to #8785.

PR Close #46868
2022-08-22 16:00:35 -07:00
George Kalpakas e9cb0454dc feat(upgrade): more closely align UpgradeModule#bootstrap() with angular.bootstrap() (#46214)
Previously, [UpgradeModule#bootstrap()][1], while being a replacement
for and accepting the same arguments as [angular.bootstrap()][2], did
not return the same value as `angular.bootstrap()` (i.e. the AngularJS
injector in most cases). This made it less straight forward to migrate
some usecases that relied on the return value of `.bootstrap()`. The
work-around was to access the injector via [UpgradeModule#$injector][3]
(after the app had been bootstrapped with `UpgradeModule#bootstrap()`).

This commit addresses this by ensuring `UpgradeModule#bootstrap()`
returns the same value as `angular.bootstrap()`, making it easier to
replace the latter with the former.

[1]: https://angular.io/api/upgrade/static/UpgradeModule#bootstrap
[2]: https://docs.angularjs.org/api/ng/function/angular.bootstrap
[3]: https://angular.io/api/upgrade/static/UpgradeModule#%24injector

Fixes #46211

PR Close #46214
2022-06-03 10:16:05 -07:00
Alex Rickabaugh d3c0fa3b1a refactor(compiler-cli): propagate standalone flag in .d.ts metadata (#45672)
This commit adds a type field to .d.ts metadata for directives, components,
and pipes which carries a boolean literal indicating whether the given type
is standalone or not. For backwards compatibility, this flag defaults to
`false`.

Tests are added to validate that standalone types coming from .d.ts files
can be correctly imported into new standalone components.

PR Close #45672
2022-04-20 05:45:57 -07:00
Paul Gschwendtner 209a73ede6 test: update api goldens to reflect api-golden bazel rule change (#45461)
The API golden Bazel rule has changed in the shared dev-infra code. Instead
of putting golden API reports into the golden folder as per their original
location in the NPM package, golden reports are now stored based on the
package exports. This makes it more obvious how entry-points are consumable

As part of this change, since the API golden rule now consutls the NPM package
`exports` field, the `localize/tools` entry-point golden file is now generated.

Previously it wasn't generated due to it not having a secondary entry-point
`package.json` file. Such package json files should not be needed anymore
and will be gone in future APF versions.

PR Close #45461
2022-03-29 09:26:00 -07:00