2018-02-16 08:45:21 -08:00
|
|
|
/**
|
|
|
|
* @license
|
|
|
|
* Copyright Google Inc. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* 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 {StaticSymbol} from '../aot/static_symbol';
|
|
|
|
import {CompileShallowModuleMetadata, identifierName} from '../compile_metadata';
|
|
|
|
import {InjectableCompiler} from '../injectable_compiler';
|
|
|
|
import {mapLiteral} from '../output/map_util';
|
|
|
|
import * as o from '../output/output_ast';
|
|
|
|
import {OutputContext} from '../util';
|
|
|
|
|
2018-06-18 16:28:02 -07:00
|
|
|
import {R3DependencyMetadata, compileFactoryFunction} from './r3_factory';
|
2018-02-16 08:45:21 -08:00
|
|
|
import {Identifiers as R3} from './r3_identifiers';
|
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
|
|
|
import {R3Reference, convertMetaToOutput, mapToMapExpression} 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
|
|
|
/**
|
|
|
|
* Metadata required by the module compiler to generate a `ngModuleDef` for a type.
|
|
|
|
*/
|
|
|
|
export interface R3NgModuleMetadata {
|
|
|
|
/**
|
|
|
|
* An expression representing the module type being compiled.
|
|
|
|
*/
|
|
|
|
type: o.Expression;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Construct an `R3NgModuleDef` for the given `R3NgModuleMetadata`.
|
|
|
|
*/
|
|
|
|
export function compileNgModule(meta: R3NgModuleMetadata): R3NgModuleDef {
|
|
|
|
const {type: moduleType, bootstrap, declarations, imports, exports} = meta;
|
|
|
|
const expression = o.importExpr(R3.defineNgModule).callFn([mapToMapExpression({
|
|
|
|
type: moduleType,
|
2018-08-28 14:19:33 -07:00
|
|
|
bootstrap: o.literalArr(bootstrap.map(ref => ref.value)),
|
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: o.literalArr(declarations.map(ref => ref.value)),
|
|
|
|
imports: o.literalArr(imports.map(ref => ref.value)),
|
|
|
|
exports: o.literalArr(exports.map(ref => ref.value)),
|
2018-05-09 08:35:25 -07:00
|
|
|
})]);
|
|
|
|
|
2018-09-21 12:12:06 -07:00
|
|
|
const type = new o.ExpressionType(o.importExpr(R3.NgModuleDefWithMeta, [
|
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
|
|
|
new o.ExpressionType(moduleType), tupleTypeOf(declarations), tupleTypeOf(imports),
|
|
|
|
tupleTypeOf(exports)
|
2018-05-31 15:50:02 -07:00
|
|
|
]));
|
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
const additionalStatements: o.Statement[] = [];
|
|
|
|
return {expression, type, additionalStatements};
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
type: o.Expression;
|
2018-07-16 16:36:31 -07:00
|
|
|
deps: R3DependencyMetadata[]|null;
|
2018-06-18 16:28:02 -07:00
|
|
|
providers: o.Expression;
|
|
|
|
imports: o.Expression;
|
|
|
|
}
|
|
|
|
|
|
|
|
export function compileInjector(meta: R3InjectorMetadata): R3InjectorDef {
|
2018-07-16 16:36:31 -07:00
|
|
|
const result = compileFactoryFunction({
|
|
|
|
name: meta.name,
|
|
|
|
type: meta.type,
|
|
|
|
deps: meta.deps,
|
|
|
|
injectFn: R3.inject,
|
|
|
|
});
|
2018-06-18 16:28:02 -07:00
|
|
|
const expression = o.importExpr(R3.defineInjector).callFn([mapToMapExpression({
|
2018-07-16 16:36:31 -07:00
|
|
|
factory: result.factory,
|
2018-06-18 16:28:02 -07:00
|
|
|
providers: meta.providers,
|
|
|
|
imports: meta.imports,
|
|
|
|
})]);
|
2018-06-29 14:03:18 -07:00
|
|
|
const type =
|
|
|
|
new o.ExpressionType(o.importExpr(R3.InjectorDef, [new o.ExpressionType(meta.type)]));
|
2018-07-16 16:36:31 -07:00
|
|
|
return {expression, type, statements: result.statements};
|
2018-06-18 16:28:02 -07:00
|
|
|
}
|
|
|
|
|
2018-05-09 08:35:25 -07:00
|
|
|
// TODO(alxhub): integrate this with `compileNgModule`. Currently the two are separate operations.
|
|
|
|
export function compileNgModuleFromRender2(
|
2018-02-16 08:45:21 -08:00
|
|
|
ctx: OutputContext, ngModule: CompileShallowModuleMetadata,
|
|
|
|
injectableCompiler: InjectableCompiler): void {
|
|
|
|
const className = identifierName(ngModule.type) !;
|
|
|
|
|
|
|
|
const rawImports = ngModule.rawImports ? [ngModule.rawImports] : [];
|
|
|
|
const rawExports = ngModule.rawExports ? [ngModule.rawExports] : [];
|
|
|
|
|
|
|
|
const injectorDefArg = mapLiteral({
|
|
|
|
'factory':
|
|
|
|
injectableCompiler.factoryFor({type: ngModule.type, symbol: ngModule.type.reference}, ctx),
|
|
|
|
'providers': convertMetaToOutput(ngModule.rawProviders, ctx),
|
|
|
|
'imports': convertMetaToOutput([...rawImports, ...rawExports], ctx),
|
|
|
|
});
|
|
|
|
|
|
|
|
const injectorDef = o.importExpr(R3.defineInjector).callFn([injectorDefArg]);
|
|
|
|
|
|
|
|
ctx.statements.push(new o.ClassStmt(
|
|
|
|
/* name */ className,
|
|
|
|
/* parent */ null,
|
|
|
|
/* fields */[new o.ClassField(
|
|
|
|
/* name */ 'ngInjectorDef',
|
|
|
|
/* type */ o.INFERRED_TYPE,
|
|
|
|
/* modifiers */[o.StmtModifier.Static],
|
|
|
|
/* initializer */ injectorDef, )],
|
|
|
|
/* getters */[],
|
|
|
|
/* constructorMethod */ new o.ClassMethod(null, [], []),
|
|
|
|
/* methods */[]));
|
2018-05-09 08:35:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
function accessExportScope(module: o.Expression): o.Expression {
|
|
|
|
const selectorScope = new o.ReadPropExpr(module, 'ngModuleDef');
|
|
|
|
return new o.ReadPropExpr(selectorScope, 'exported');
|
|
|
|
}
|
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
|
|
|
|
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;
|
|
|
|
}
|