2018-02-16 08:45:21 -08:00
|
|
|
/**
|
|
|
|
* @license
|
2020-05-19 12:08:49 -07:00
|
|
|
* Copyright Google LLC All Rights Reserved.
|
2018-02-16 08:45:21 -08: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
|
|
|
|
*/
|
|
|
|
|
|
|
|
import * as o from '../output/output_ast';
|
|
|
|
|
2020-04-08 10:14:18 -07:00
|
|
|
import {compileFactoryFunction, R3DependencyMetadata, R3FactoryTarget} from './r3_factory';
|
2018-02-16 08:45:21 -08:00
|
|
|
import {Identifiers as R3} from './r3_identifiers';
|
2021-02-25 14:11:30 +00:00
|
|
|
import {jitOnlyGuardedExpression, mapToMapExpression, R3Reference} from './util';
|
2018-02-16 08:45:21 -08:00
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
export interface R3NgModuleDef {
|
|
|
|
expression: o.Expression;
|
|
|
|
type: o.Type;
|
|
|
|
additionalStatements: o.Statement[];
|
2018-02-16 08:45:21 -08:00
|
|
|
}
|
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
/**
|
2019-10-14 07:20:26 -07:00
|
|
|
* Metadata required by the module compiler to generate a module def (`ɵmod`) for a type.
|
2018-05-09 08:35:25 -07:00
|
|
|
*/
|
|
|
|
export interface R3NgModuleMetadata {
|
|
|
|
/**
|
|
|
|
* An expression representing the module type being compiled.
|
|
|
|
*/
|
2019-12-18 14:03:05 +00:00
|
|
|
type: R3Reference;
|
2018-05-09 08:35:25 -07:00
|
|
|
|
refactor(ivy): split `type` into `type`, `internalType` and `adjacentType` (#33533)
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close #33533
2019-11-01 16:55:09 +00:00
|
|
|
/**
|
|
|
|
* An expression representing the module type being compiled, intended for use within a class
|
|
|
|
* definition itself.
|
|
|
|
*
|
|
|
|
* This can differ from the outer `type` if the class is being compiled by ngcc and is inside
|
|
|
|
* an IIFE structure that uses a different name internally.
|
|
|
|
*/
|
|
|
|
internalType: o.Expression;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An expression intended for use by statements that are adjacent (i.e. tightly coupled) to but
|
|
|
|
* not internal to a class definition.
|
|
|
|
*
|
|
|
|
* This can differ from the outer `type` if the class is being compiled by ngcc and is inside
|
|
|
|
* an IIFE structure that uses a different name internally.
|
|
|
|
*/
|
|
|
|
adjacentType: o.Expression;
|
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
/**
|
|
|
|
* An array of expressions representing the bootstrap components specified by the module.
|
|
|
|
*/
|
2018-08-28 14:19:33 -07:00
|
|
|
bootstrap: R3Reference[];
|
2018-05-09 08:35:25 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* An array of expressions representing the directives and pipes declared by the module.
|
|
|
|
*/
|
fix(ivy): force new imports for .d.ts files (#25080)
When ngtsc encounters a reference to a type (for example, a Component
type listed in an NgModule declarations array), it traces the import
of that type and attempts to determine the best way to refer to it.
In the event the type is defined in the same file where a reference
is being generated, the identifier of the type is used. If the type
was imported, ngtsc has a choice. It can use the identifier from the
original import, or it can write a new import to the module where the
type came from.
ngtsc has a bug currently when it elects to rely on the user's import.
When writing a .d.ts file, the user's import may have been elided as
the type was not referred to from the type side of the program. Thus,
in .d.ts files ngtsc must always assume the import may not exist, and
generate a new one.
In .js output the import is guaranteed to still exist, so it's
preferable for ngtsc to continue using the existing import if one is
available.
This commit changes how @angular/compiler writes type definitions, and
allows it to use a different expression to write a type definition than
is used to write the value. This allows ngtsc to specify that types in
type definitions should always be imported. A corresponding change to
the staticallyResolve() Reference system allows the choice of which
type of import to use when generating an Expression from a Reference.
PR Close #25080
2018-07-24 16:10:15 -07:00
|
|
|
declarations: R3Reference[];
|
2018-05-09 08:35:25 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* An array of expressions representing the imports of the module.
|
|
|
|
*/
|
fix(ivy): force new imports for .d.ts files (#25080)
When ngtsc encounters a reference to a type (for example, a Component
type listed in an NgModule declarations array), it traces the import
of that type and attempts to determine the best way to refer to it.
In the event the type is defined in the same file where a reference
is being generated, the identifier of the type is used. If the type
was imported, ngtsc has a choice. It can use the identifier from the
original import, or it can write a new import to the module where the
type came from.
ngtsc has a bug currently when it elects to rely on the user's import.
When writing a .d.ts file, the user's import may have been elided as
the type was not referred to from the type side of the program. Thus,
in .d.ts files ngtsc must always assume the import may not exist, and
generate a new one.
In .js output the import is guaranteed to still exist, so it's
preferable for ngtsc to continue using the existing import if one is
available.
This commit changes how @angular/compiler writes type definitions, and
allows it to use a different expression to write a type definition than
is used to write the value. This allows ngtsc to specify that types in
type definitions should always be imported. A corresponding change to
the staticallyResolve() Reference system allows the choice of which
type of import to use when generating an Expression from a Reference.
PR Close #25080
2018-07-24 16:10:15 -07:00
|
|
|
imports: R3Reference[];
|
2018-05-09 08:35:25 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* An array of expressions representing the exports of the module.
|
|
|
|
*/
|
fix(ivy): force new imports for .d.ts files (#25080)
When ngtsc encounters a reference to a type (for example, a Component
type listed in an NgModule declarations array), it traces the import
of that type and attempts to determine the best way to refer to it.
In the event the type is defined in the same file where a reference
is being generated, the identifier of the type is used. If the type
was imported, ngtsc has a choice. It can use the identifier from the
original import, or it can write a new import to the module where the
type came from.
ngtsc has a bug currently when it elects to rely on the user's import.
When writing a .d.ts file, the user's import may have been elided as
the type was not referred to from the type side of the program. Thus,
in .d.ts files ngtsc must always assume the import may not exist, and
generate a new one.
In .js output the import is guaranteed to still exist, so it's
preferable for ngtsc to continue using the existing import if one is
available.
This commit changes how @angular/compiler writes type definitions, and
allows it to use a different expression to write a type definition than
is used to write the value. This allows ngtsc to specify that types in
type definitions should always be imported. A corresponding change to
the staticallyResolve() Reference system allows the choice of which
type of import to use when generating an Expression from a Reference.
PR Close #25080
2018-07-24 16:10:15 -07:00
|
|
|
exports: R3Reference[];
|
2018-05-09 08:35:25 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Whether to emit the selector scope values (declarations, imports, exports) inline into the
|
|
|
|
* module definition, or to generate additional statements which patch them on. Inline emission
|
|
|
|
* does not allow components to be tree-shaken, but is useful for JIT mode.
|
|
|
|
*/
|
|
|
|
emitInline: boolean;
|
2019-02-12 00:03:04 +01:00
|
|
|
|
2019-03-08 17:57:34 -08:00
|
|
|
/**
|
|
|
|
* Whether to generate closure wrappers for bootstrap, declarations, imports, and exports.
|
|
|
|
*/
|
|
|
|
containsForwardDecls: boolean;
|
|
|
|
|
2019-02-12 00:03:04 +01:00
|
|
|
/**
|
|
|
|
* The set of schemas that declare elements to be allowed in the NgModule.
|
|
|
|
*/
|
|
|
|
schemas: R3Reference[]|null;
|
2019-05-07 22:57:55 -04:00
|
|
|
|
|
|
|
/** Unique ID or expression representing the unique ID of an NgModule. */
|
|
|
|
id: o.Expression|null;
|
2018-05-09 08:35:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Construct an `R3NgModuleDef` for the given `R3NgModuleMetadata`.
|
|
|
|
*/
|
|
|
|
export function compileNgModule(meta: R3NgModuleMetadata): R3NgModuleDef {
|
2019-03-08 17:57:34 -08:00
|
|
|
const {
|
refactor(ivy): split `type` into `type`, `internalType` and `adjacentType` (#33533)
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close #33533
2019-11-01 16:55:09 +00:00
|
|
|
internalType,
|
2019-03-08 17:57:34 -08:00
|
|
|
type: moduleType,
|
|
|
|
bootstrap,
|
|
|
|
declarations,
|
|
|
|
imports,
|
|
|
|
exports,
|
|
|
|
schemas,
|
2019-03-29 21:31:22 +01:00
|
|
|
containsForwardDecls,
|
2019-05-07 22:57:55 -04:00
|
|
|
emitInline,
|
|
|
|
id
|
2019-03-08 17:57:34 -08:00
|
|
|
} = meta;
|
|
|
|
|
2019-03-29 21:31:22 +01:00
|
|
|
const additionalStatements: o.Statement[] = [];
|
2020-04-08 10:14:18 -07:00
|
|
|
const definitionMap = {type: internalType} as {
|
2019-01-26 12:29:38 +01:00
|
|
|
type: o.Expression,
|
2019-03-08 17:57:34 -08:00
|
|
|
bootstrap: o.Expression,
|
|
|
|
declarations: o.Expression,
|
|
|
|
imports: o.Expression,
|
|
|
|
exports: o.Expression,
|
2019-05-07 22:57:55 -04:00
|
|
|
schemas: o.LiteralArrayExpr,
|
|
|
|
id: o.Expression
|
2019-01-26 12:29:38 +01:00
|
|
|
};
|
2018-05-09 08:35:25 -07:00
|
|
|
|
2019-01-26 12:29:38 +01:00
|
|
|
// Only generate the keys in the metadata if the arrays have values.
|
|
|
|
if (bootstrap.length) {
|
2019-03-08 17:57:34 -08:00
|
|
|
definitionMap.bootstrap = refsToArray(bootstrap, containsForwardDecls);
|
2019-01-26 12:29:38 +01:00
|
|
|
}
|
|
|
|
|
2019-03-29 21:31:22 +01:00
|
|
|
// If requested to emit scope information inline, pass the declarations, imports and exports to
|
2019-05-17 18:49:21 -07:00
|
|
|
// the `ɵɵdefineNgModule` call. The JIT compilation uses this.
|
2019-03-29 21:31:22 +01:00
|
|
|
if (emitInline) {
|
|
|
|
if (declarations.length) {
|
|
|
|
definitionMap.declarations = refsToArray(declarations, containsForwardDecls);
|
|
|
|
}
|
2019-01-26 12:29:38 +01:00
|
|
|
|
2019-03-29 21:31:22 +01:00
|
|
|
if (imports.length) {
|
|
|
|
definitionMap.imports = refsToArray(imports, containsForwardDecls);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exports.length) {
|
|
|
|
definitionMap.exports = refsToArray(exports, containsForwardDecls);
|
|
|
|
}
|
2019-01-26 12:29:38 +01:00
|
|
|
}
|
|
|
|
|
2019-05-17 18:49:21 -07:00
|
|
|
// If not emitting inline, the scope information is not passed into `ɵɵdefineNgModule` as it would
|
2019-03-29 21:31:22 +01:00
|
|
|
// prevent tree-shaking of the declarations, imports and exports references.
|
|
|
|
else {
|
|
|
|
const setNgModuleScopeCall = generateSetNgModuleScopeCall(meta);
|
|
|
|
if (setNgModuleScopeCall !== null) {
|
|
|
|
additionalStatements.push(setNgModuleScopeCall);
|
|
|
|
}
|
2019-01-26 12:29:38 +01:00
|
|
|
}
|
|
|
|
|
2019-02-12 00:03:04 +01:00
|
|
|
if (schemas && schemas.length) {
|
|
|
|
definitionMap.schemas = o.literalArr(schemas.map(ref => ref.value));
|
|
|
|
}
|
|
|
|
|
2019-05-07 22:57:55 -04:00
|
|
|
if (id) {
|
|
|
|
definitionMap.id = id;
|
|
|
|
}
|
|
|
|
|
2021-03-05 16:25:04 -08:00
|
|
|
const expression =
|
|
|
|
o.importExpr(R3.defineNgModule).callFn([mapToMapExpression(definitionMap)], undefined, true);
|
2018-09-21 12:12:06 -07:00
|
|
|
const type = new o.ExpressionType(o.importExpr(R3.NgModuleDefWithMeta, [
|
2019-12-18 14:03:05 +00:00
|
|
|
new o.ExpressionType(moduleType.type), tupleTypeOf(declarations), tupleTypeOf(imports),
|
fix(ivy): use 'typeof' and 'never' for type metadata (#24862)
Previously ngtsc would use a tuple of class types for listing metadata
in .d.ts files. For example, an @NgModule's declarations might be
represented with the type:
[NgIf, NgForOf, NgClass]
If the module had no declarations, an empty tuple [] would be produced.
This has two problems.
1. If the class type has generic type parameters, TypeScript will
complain that they're not provided.
2. The empty tuple type is not actually legal.
This commit addresses both problems.
1. Class types are now represented using the `typeof` operator, so the
above declarations would be represented as:
[typeof NgIf, typeof NgForOf, typeof NgClass].
Since typeof operates on a value, it doesn't require generic type
arguments.
2. Instead of an empty tuple, `never` is used to indicate no metadata.
PR Close #24862
2018-07-17 13:34:20 -07:00
|
|
|
tupleTypeOf(exports)
|
2018-05-31 15:50:02 -07:00
|
|
|
]));
|
|
|
|
|
2019-03-29 21:31:22 +01:00
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
return {expression, type, additionalStatements};
|
|
|
|
}
|
|
|
|
|
2019-03-29 21:31:22 +01:00
|
|
|
/**
|
2019-05-17 18:49:21 -07:00
|
|
|
* Generates a function call to `ɵɵsetNgModuleScope` with all necessary information so that the
|
2019-03-29 21:31:22 +01:00
|
|
|
* transitive module scope can be computed during runtime in JIT mode. This call is marked pure
|
|
|
|
* such that the references to declarations, imports and exports may be elided causing these
|
|
|
|
* symbols to become tree-shakeable.
|
|
|
|
*/
|
|
|
|
function generateSetNgModuleScopeCall(meta: R3NgModuleMetadata): o.Statement|null {
|
refactor(ivy): split `type` into `type`, `internalType` and `adjacentType` (#33533)
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close #33533
2019-11-01 16:55:09 +00:00
|
|
|
const {adjacentType: moduleType, declarations, imports, exports, containsForwardDecls} = meta;
|
2019-03-29 21:31:22 +01:00
|
|
|
|
2020-04-08 10:14:18 -07:00
|
|
|
const scopeMap = {} as {
|
2019-03-29 21:31:22 +01:00
|
|
|
declarations: o.Expression,
|
|
|
|
imports: o.Expression,
|
|
|
|
exports: o.Expression,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (declarations.length) {
|
|
|
|
scopeMap.declarations = refsToArray(declarations, containsForwardDecls);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (imports.length) {
|
|
|
|
scopeMap.imports = refsToArray(imports, containsForwardDecls);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (exports.length) {
|
|
|
|
scopeMap.exports = refsToArray(exports, containsForwardDecls);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Object.keys(scopeMap).length === 0) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
fix(ivy): retain JIT metadata unless JIT mode is explicitly disabled (#33671)
NgModules in Ivy have a definition which contains various different bits
of metadata about the module. In particular, this metadata falls into two
categories:
* metadata required to use the module at runtime (for bootstrapping, etc)
in AOT-only applications.
* metadata required to depend on the module from a JIT-compiled app.
The latter metadata consists of the module's declarations, imports, and
exports. To support JIT usage, this metadata must be included in the
generated code, especially if that code is shipped to NPM. However, because
this metadata preserves the entire NgModule graph (references to all
directives and components in the app), it needs to be removed during
optimization for AOT-only builds.
Previously, this was done with a clever design:
1. The extra metadata was added by a function called `setNgModuleScope`.
A call to this function was generated after each NgModule.
2. This function call was marked as "pure" with a comment and used
`noSideEffects` internally, which causes optimizers to remove it.
The effect was that in dev mode or test mode (which use JIT), no optimizer
runs and the full NgModule metadata was available at runtime. But in
production (presumably AOT) builds, the optimizer runs and removes the JIT-
specific metadata.
However, there are cases where apps that want to use JIT in production, and
still make an optimized build. In this case, the JIT-specific metadata would
be erroneously removed. This commit solves that problem by adding an
`ngJitMode` global variable which guards all `setNgModuleScope` calls. An
optimizer can be configured to statically define this global to be `false`
for AOT-only builds, causing the extra metadata to be stripped.
A configuration for Terser used by the CLI is provided in `tooling.ts` which
sets `ngJitMode` to `false` when building AOT apps.
PR Close #33671
2019-11-07 14:18:44 -08:00
|
|
|
// setNgModuleScope(...)
|
2019-03-29 21:31:22 +01:00
|
|
|
const fnCall = new o.InvokeFunctionExpr(
|
|
|
|
/* fn */ o.importExpr(R3.setNgModuleScope),
|
fix(ivy): retain JIT metadata unless JIT mode is explicitly disabled (#33671)
NgModules in Ivy have a definition which contains various different bits
of metadata about the module. In particular, this metadata falls into two
categories:
* metadata required to use the module at runtime (for bootstrapping, etc)
in AOT-only applications.
* metadata required to depend on the module from a JIT-compiled app.
The latter metadata consists of the module's declarations, imports, and
exports. To support JIT usage, this metadata must be included in the
generated code, especially if that code is shipped to NPM. However, because
this metadata preserves the entire NgModule graph (references to all
directives and components in the app), it needs to be removed during
optimization for AOT-only builds.
Previously, this was done with a clever design:
1. The extra metadata was added by a function called `setNgModuleScope`.
A call to this function was generated after each NgModule.
2. This function call was marked as "pure" with a comment and used
`noSideEffects` internally, which causes optimizers to remove it.
The effect was that in dev mode or test mode (which use JIT), no optimizer
runs and the full NgModule metadata was available at runtime. But in
production (presumably AOT) builds, the optimizer runs and removes the JIT-
specific metadata.
However, there are cases where apps that want to use JIT in production, and
still make an optimized build. In this case, the JIT-specific metadata would
be erroneously removed. This commit solves that problem by adding an
`ngJitMode` global variable which guards all `setNgModuleScope` calls. An
optimizer can be configured to statically define this global to be `false`
for AOT-only builds, causing the extra metadata to be stripped.
A configuration for Terser used by the CLI is provided in `tooling.ts` which
sets `ngJitMode` to `false` when building AOT apps.
PR Close #33671
2019-11-07 14:18:44 -08:00
|
|
|
/* args */[moduleType, mapToMapExpression(scopeMap)]);
|
|
|
|
|
|
|
|
// (ngJitMode guard) && setNgModuleScope(...)
|
|
|
|
const guardedCall = jitOnlyGuardedExpression(fnCall);
|
|
|
|
|
|
|
|
// function() { (ngJitMode guard) && setNgModuleScope(...); }
|
|
|
|
const iife = new o.FunctionExpr(
|
|
|
|
/* params */[],
|
|
|
|
/* statements */[guardedCall.toStmt()]);
|
|
|
|
|
|
|
|
// (function() { (ngJitMode guard) && setNgModuleScope(...); })()
|
|
|
|
const iifeCall = new o.InvokeFunctionExpr(
|
|
|
|
/* fn */ iife,
|
|
|
|
/* args */[]);
|
|
|
|
|
|
|
|
return iifeCall.toStmt();
|
2019-03-29 21:31:22 +01:00
|
|
|
}
|
|
|
|
|
2018-06-18 16:28:02 -07:00
|
|
|
export interface R3InjectorDef {
|
|
|
|
expression: o.Expression;
|
|
|
|
type: o.Type;
|
2018-07-16 16:36:31 -07:00
|
|
|
statements: o.Statement[];
|
2018-06-18 16:28:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
export interface R3InjectorMetadata {
|
|
|
|
name: string;
|
2019-12-18 14:03:05 +00:00
|
|
|
type: R3Reference;
|
refactor(ivy): split `type` into `type`, `internalType` and `adjacentType` (#33533)
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close #33533
2019-11-01 16:55:09 +00:00
|
|
|
internalType: o.Expression;
|
2018-07-16 16:36:31 -07:00
|
|
|
deps: R3DependencyMetadata[]|null;
|
2019-03-30 14:12:25 +01:00
|
|
|
providers: o.Expression|null;
|
2019-03-30 13:09:45 +01:00
|
|
|
imports: o.Expression[];
|
2018-06-18 16:28:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
export function compileInjector(meta: R3InjectorMetadata): R3InjectorDef {
|
2018-07-16 16:36:31 -07:00
|
|
|
const result = compileFactoryFunction({
|
|
|
|
name: meta.name,
|
|
|
|
type: meta.type,
|
refactor(ivy): split `type` into `type`, `internalType` and `adjacentType` (#33533)
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close #33533
2019-11-01 16:55:09 +00:00
|
|
|
internalType: meta.internalType,
|
2019-08-12 09:26:20 +03:00
|
|
|
typeArgumentCount: 0,
|
2018-07-16 16:36:31 -07:00
|
|
|
deps: meta.deps,
|
|
|
|
injectFn: R3.inject,
|
2019-10-03 21:54:49 +02:00
|
|
|
target: R3FactoryTarget.NgModule,
|
2018-07-16 16:36:31 -07:00
|
|
|
});
|
2019-03-30 14:12:25 +01:00
|
|
|
const definitionMap = {
|
2018-07-16 16:36:31 -07:00
|
|
|
factory: result.factory,
|
2020-04-08 10:14:18 -07:00
|
|
|
} as {factory: o.Expression, providers: o.Expression, imports: o.Expression};
|
2019-03-30 14:12:25 +01:00
|
|
|
|
|
|
|
if (meta.providers !== null) {
|
|
|
|
definitionMap.providers = meta.providers;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (meta.imports.length > 0) {
|
|
|
|
definitionMap.imports = o.literalArr(meta.imports);
|
|
|
|
}
|
|
|
|
|
2021-03-05 16:25:04 -08:00
|
|
|
const expression =
|
|
|
|
o.importExpr(R3.defineInjector).callFn([mapToMapExpression(definitionMap)], undefined, true);
|
2018-06-29 14:03:18 -07:00
|
|
|
const type =
|
2019-12-18 14:03:05 +00:00
|
|
|
new o.ExpressionType(o.importExpr(R3.InjectorDef, [new o.ExpressionType(meta.type.type)]));
|
2018-07-16 16:36:31 -07:00
|
|
|
return {expression, type, statements: result.statements};
|
2018-06-18 16:28:02 -07:00
|
|
|
}
|
|
|
|
|
fix(ivy): force new imports for .d.ts files (#25080)
When ngtsc encounters a reference to a type (for example, a Component
type listed in an NgModule declarations array), it traces the import
of that type and attempts to determine the best way to refer to it.
In the event the type is defined in the same file where a reference
is being generated, the identifier of the type is used. If the type
was imported, ngtsc has a choice. It can use the identifier from the
original import, or it can write a new import to the module where the
type came from.
ngtsc has a bug currently when it elects to rely on the user's import.
When writing a .d.ts file, the user's import may have been elided as
the type was not referred to from the type side of the program. Thus,
in .d.ts files ngtsc must always assume the import may not exist, and
generate a new one.
In .js output the import is guaranteed to still exist, so it's
preferable for ngtsc to continue using the existing import if one is
available.
This commit changes how @angular/compiler writes type definitions, and
allows it to use a different expression to write a type definition than
is used to write the value. This allows ngtsc to specify that types in
type definitions should always be imported. A corresponding change to
the staticallyResolve() Reference system allows the choice of which
type of import to use when generating an Expression from a Reference.
PR Close #25080
2018-07-24 16:10:15 -07:00
|
|
|
function tupleTypeOf(exp: R3Reference[]): o.Type {
|
|
|
|
const types = exp.map(ref => o.typeofExpr(ref.type));
|
fix(ivy): use 'typeof' and 'never' for type metadata (#24862)
Previously ngtsc would use a tuple of class types for listing metadata
in .d.ts files. For example, an @NgModule's declarations might be
represented with the type:
[NgIf, NgForOf, NgClass]
If the module had no declarations, an empty tuple [] would be produced.
This has two problems.
1. If the class type has generic type parameters, TypeScript will
complain that they're not provided.
2. The empty tuple type is not actually legal.
This commit addresses both problems.
1. Class types are now represented using the `typeof` operator, so the
above declarations would be represented as:
[typeof NgIf, typeof NgForOf, typeof NgClass].
Since typeof operates on a value, it doesn't require generic type
arguments.
2. Instead of an empty tuple, `never` is used to indicate no metadata.
PR Close #24862
2018-07-17 13:34:20 -07:00
|
|
|
return exp.length > 0 ? o.expressionType(o.literalArr(types)) : o.NONE_TYPE;
|
2018-10-16 10:28:23 -07:00
|
|
|
}
|
2019-03-08 17:57:34 -08:00
|
|
|
|
|
|
|
function refsToArray(refs: R3Reference[], shouldForwardDeclare: boolean): o.Expression {
|
|
|
|
const values = o.literalArr(refs.map(ref => ref.value));
|
|
|
|
return shouldForwardDeclare ? o.fn([], [new o.ReturnStatement(values)]) : values;
|
2019-03-29 21:31:22 +01:00
|
|
|
}
|