feat(ngcc): add a migration for undecorated child classes (#33362)
In Angular View Engine, there are two kinds of decorator inheritance:
1) both the parent and child classes have decorators
This case is supported by InheritDefinitionFeature, which merges some fields
of the definitions (such as the inputs or queries).
2) only the parent class has a decorator
If the child class is missing a decorator, the compiler effectively behaves
as if the parent class' decorator is applied to the child class as well.
This is the "undecorated child" scenario, and this commit adds a migration
to ngcc to support this pattern in Ivy.
This migration has 2 phases. First, the NgModules of the application are
scanned for classes in 'declarations' which are missing decorators, but
whose base classes do have decorators. These classes are the undecorated
children. This scan is performed recursively, so even if a declared class
has a base class that itself inherits a decorator, this case is handled.
Next, a synthetic decorator (either @Component or @Directive) is created
on the child class. This decorator copies some critical information such
as 'selector' and 'exportAs', as well as supports any decorated fields
(@Input, etc). A flag is passed to the decorator compiler which causes a
special feature `CopyDefinitionFeature` to be included on the compiled
definition. This feature copies at runtime the remaining aspects of the
parent definition which `InheritDefinitionFeature` does not handle,
completing the "full" inheritance of the child class' decorator from its
parent class.
PR Close #33362
2019-10-23 19:00:49 +00:00
|
|
|
/**
|
|
|
|
|
* @license
|
2020-05-19 19:08:49 +00:00
|
|
|
* Copyright Google LLC All Rights Reserved.
|
feat(ngcc): add a migration for undecorated child classes (#33362)
In Angular View Engine, there are two kinds of decorator inheritance:
1) both the parent and child classes have decorators
This case is supported by InheritDefinitionFeature, which merges some fields
of the definitions (such as the inputs or queries).
2) only the parent class has a decorator
If the child class is missing a decorator, the compiler effectively behaves
as if the parent class' decorator is applied to the child class as well.
This is the "undecorated child" scenario, and this commit adds a migration
to ngcc to support this pattern in Ivy.
This migration has 2 phases. First, the NgModules of the application are
scanned for classes in 'declarations' which are missing decorators, but
whose base classes do have decorators. These classes are the undecorated
children. This scan is performed recursively, so even if a declared class
has a base class that itself inherits a decorator, this case is handled.
Next, a synthetic decorator (either @Component or @Directive) is created
on the child class. This decorator copies some critical information such
as 'selector' and 'exportAs', as well as supports any decorated fields
(@Input, etc). A flag is passed to the decorator compiler which causes a
special feature `CopyDefinitionFeature` to be included on the compiled
definition. This feature copies at runtime the remaining aspects of the
parent definition which `InheritDefinitionFeature` does not handle,
completing the "full" inheritance of the child class' decorator from its
parent class.
PR Close #33362
2019-10-23 19:00:49 +00:00
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
|
|
|
* found in the LICENSE file at https://angular.io/license
|
|
|
|
|
*/
|
|
|
|
|
|
test(ngcc): don't use the workspace typescript version to generate integration test fixtures (#44448)
Now that ViewEngine libraries can no longer be created, the latest
TypeScript version that ngcc should be able to process is TypeScript 4.3,
i.e. the version of TypeScript that was supported in Angular 12.
However, ngcc's integration tests used the TypeScript version of the
workspace to create the JavaScript files from TypeScript sources on
demand. This introduces friction when upgrading the TypeScript version
within the workspace, as changes to TypeScript's emit format may affect
ngcc's ability to process it correctly.
The on demand creation of JavaScript files was convenient for authoring
tests, but it also helped to detect incompatibilities with newer
versions of TypeScript. Now that ngcc no longer has to process newer
versions of TypeScript, we want to pin the integration suite to use
JavaScript code as if it were compiled using TypeScript 4.3, i.e. a
version of TypeScript that is actually supported by ngcc.
This commit updates the integration test to inline all the generated
files directly in the tests, instead of compiling them on demand. This
was done by temporarily installing TypeScript 4.3 and using it to create
the `loadTestFiles` statement from the original TypeScript inputs.
An alternative could have been to install TypeScript 4.3 as an actual
dependency in the workspace and using that to continue compiling the
integration suite on demand, but this brings some overhead in package
installations (TypeScript is ~60MB) and the authoring aspect of ngcc
integration test is expected to diminish, now that ngcc's support is no
longer a moving target.
PR Close #44448
2021-12-11 22:55:48 +00:00
|
|
|
import {AbsoluteFsPath} from '../../../src/ngtsc/file_system';
|
2021-08-23 20:28:29 +00:00
|
|
|
import {Folder, MockFileSystemPosix} from '../../../src/ngtsc/file_system/testing';
|
|
|
|
|
import {loadTestDirectory, loadTsLib, resolveNpmTreeArtifact} from '../../../src/ngtsc/testing';
|
feat(ngcc): add a migration for undecorated child classes (#33362)
In Angular View Engine, there are two kinds of decorator inheritance:
1) both the parent and child classes have decorators
This case is supported by InheritDefinitionFeature, which merges some fields
of the definitions (such as the inputs or queries).
2) only the parent class has a decorator
If the child class is missing a decorator, the compiler effectively behaves
as if the parent class' decorator is applied to the child class as well.
This is the "undecorated child" scenario, and this commit adds a migration
to ngcc to support this pattern in Ivy.
This migration has 2 phases. First, the NgModules of the application are
scanned for classes in 'declarations' which are missing decorators, but
whose base classes do have decorators. These classes are the undecorated
children. This scan is performed recursively, so even if a declared class
has a base class that itself inherits a decorator, this case is handled.
Next, a synthetic decorator (either @Component or @Directive) is created
on the child class. This decorator copies some critical information such
as 'selector' and 'exportAs', as well as supports any decorated fields
(@Input, etc). A flag is passed to the decorator compiler which causes a
special feature `CopyDefinitionFeature` to be included on the compiled
definition. This feature copies at runtime the remaining aspects of the
parent definition which `InheritDefinitionFeature` does not handle,
completing the "full" inheritance of the child class' decorator from its
parent class.
PR Close #33362
2019-10-23 19:00:49 +00:00
|
|
|
|
2021-08-23 20:28:29 +00:00
|
|
|
export function loadNgccIntegrationTestFiles(): Folder {
|
|
|
|
|
const tmpFs = new MockFileSystemPosix(true);
|
|
|
|
|
const basePath = '/' as AbsoluteFsPath;
|
|
|
|
|
|
|
|
|
|
loadTsLib(tmpFs, basePath);
|
|
|
|
|
loadTestDirectory(
|
|
|
|
|
tmpFs, resolveNpmTreeArtifact('@angular/core-12'),
|
|
|
|
|
tmpFs.resolve('/node_modules/@angular/core'));
|
|
|
|
|
loadTestDirectory(
|
|
|
|
|
tmpFs, resolveNpmTreeArtifact('@angular/common-12'),
|
|
|
|
|
tmpFs.resolve('/node_modules/@angular/common'));
|
|
|
|
|
loadTestDirectory(
|
|
|
|
|
tmpFs, resolveNpmTreeArtifact('typescript'), tmpFs.resolve('/node_modules/typescript'));
|
|
|
|
|
loadTestDirectory(tmpFs, resolveNpmTreeArtifact('rxjs'), tmpFs.resolve('/node_modules/rxjs'));
|
|
|
|
|
return tmpFs.dump();
|
|
|
|
|
}
|