2018-08-23 14:34:55 -07: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 * as ts from 'typescript';
|
|
|
|
|
|
feat(ivy): detect cycles and use remote scoping of components if needed (#28169)
By its nature, Ivy alters the import graph of a TS program, adding imports
where template dependencies exist. For example, if ComponentA uses PipeB
in its template, Ivy will insert an import of PipeB into the file in which
ComponentA is declared.
Any insertion of an import into a program has the potential to introduce a
cycle into the import graph. If for some reason the file in which PipeB is
declared imports the file in which ComponentA is declared (maybe it makes
use of a service or utility function that happens to be in the same file as
ComponentA) then this could create an import cycle. This turns out to
happen quite regularly in larger Angular codebases.
TypeScript and the Ivy runtime have no issues with such cycles. However,
other tools are not so accepting. In particular the Closure Compiler is
very anti-cycle.
To mitigate this problem, it's necessary to detect when the insertion of
an import would create a cycle. ngtsc can then use a different strategy,
known as "remote scoping", instead of directly writing a reference from
one component to another. Under remote scoping, a function
'setComponentScope' is called after the declaration of the component's
module, which does not require the addition of new imports.
FW-647 #resolve
PR Close #28169
2019-01-15 12:32:10 -08:00
|
|
|
import {CycleAnalyzer, ImportGraph} from '../../cycles';
|
2018-08-23 14:34:55 -07:00
|
|
|
import {ErrorCode, FatalDiagnosticError} from '../../diagnostics';
|
feat(ivy): use fileNameToModuleName to emit imports when it's available (#28523)
The ultimate goal of this commit is to make use of fileNameToModuleName to
get the module specifier to use when generating an import, when that API is
available in the CompilerHost that ngtsc is created with.
As part of getting there, the way in which ngtsc tracks references and
generates import module specifiers is refactored considerably. References
are tracked with the Reference class, and previously ngtsc had several
different kinds of Reference. An AbsoluteReference represented a declaration
which needed to be imported via an absolute module specifier tracked in the
AbsoluteReference, and a RelativeReference represented a declaration from
the local program, imported via relative path or referred to directly by
identifier if possible. Thus, how to refer to a particular declaration was
encoded into the Reference type _at the time of creation of the Reference_.
This commit refactors that logic and reduces Reference to a single class
with no subclasses. A Reference represents a node being referenced, plus
context about how the node was located. This context includes a
"bestGuessOwningModule", the compiler's best guess at which absolute
module specifier has defined this reference. For example, if the compiler
arrives at the declaration of CommonModule via an import to @angular/common,
then any references obtained from CommonModule (e.g. NgIf) will also be
considered to be owned by @angular/common.
A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface
are introduced. To produce an Expression referring to a given Reference'd
node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy
implementations.
Several different strategies are defined:
- LocalIdentifierStrategy: use local ts.Identifiers if available.
- AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule,
import the node via an absolute import from that module specifier.
- LogicalProjectStrategy: if the Reference is in the logical project
(is under the project rootDirs), import the node via a relative import.
- FileToModuleStrategy: use a FileToModuleHost to generate the module
specifier by which to import the node.
Depending on the availability of fileNameToModuleName in the CompilerHost,
then, a different collection of these strategies is used for compilation.
PR Close #28523
2019-02-01 17:24:21 -08:00
|
|
|
import {ModuleResolver, ReferenceEmitter} from '../../imports';
|
2018-12-18 09:48:15 -08:00
|
|
|
import {PartialEvaluator} from '../../partial_evaluator';
|
|
|
|
|
import {TypeScriptReflectionHost} from '../../reflection';
|
2019-02-19 12:05:03 -08:00
|
|
|
import {LocalModuleScopeRegistry, MetadataDtsModuleScopeResolver} from '../../scope';
|
2018-08-23 14:34:55 -07:00
|
|
|
import {getDeclaration, makeProgram} from '../../testing/in_memory_typescript';
|
|
|
|
|
import {ResourceLoader} from '../src/api';
|
|
|
|
|
import {ComponentDecoratorHandler} from '../src/component';
|
|
|
|
|
|
|
|
|
|
export class NoopResourceLoader implements ResourceLoader {
|
2019-01-16 17:22:53 +00:00
|
|
|
resolve(): string { throw new Error('Not implemented.'); }
|
|
|
|
|
canPreload = false;
|
|
|
|
|
load(): string { throw new Error('Not implemented'); }
|
|
|
|
|
preload(): Promise<void>|undefined { throw new Error('Not implemented'); }
|
2018-08-23 14:34:55 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
describe('ComponentDecoratorHandler', () => {
|
|
|
|
|
it('should produce a diagnostic when @Component has non-literal argument', () => {
|
2018-12-18 11:09:21 -08:00
|
|
|
const {program, options, host} = makeProgram([
|
2018-08-23 14:34:55 -07:00
|
|
|
{
|
|
|
|
|
name: 'node_modules/@angular/core/index.d.ts',
|
|
|
|
|
contents: 'export const Component: any;',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: 'entry.ts',
|
|
|
|
|
contents: `
|
|
|
|
|
import {Component} from '@angular/core';
|
|
|
|
|
|
|
|
|
|
const TEST = '';
|
|
|
|
|
@Component(TEST) class TestCmp {}
|
|
|
|
|
`
|
|
|
|
|
},
|
|
|
|
|
]);
|
|
|
|
|
const checker = program.getTypeChecker();
|
2018-12-18 11:09:21 -08:00
|
|
|
const reflectionHost = new TypeScriptReflectionHost(checker);
|
feat(ivy): use fileNameToModuleName to emit imports when it's available (#28523)
The ultimate goal of this commit is to make use of fileNameToModuleName to
get the module specifier to use when generating an import, when that API is
available in the CompilerHost that ngtsc is created with.
As part of getting there, the way in which ngtsc tracks references and
generates import module specifiers is refactored considerably. References
are tracked with the Reference class, and previously ngtsc had several
different kinds of Reference. An AbsoluteReference represented a declaration
which needed to be imported via an absolute module specifier tracked in the
AbsoluteReference, and a RelativeReference represented a declaration from
the local program, imported via relative path or referred to directly by
identifier if possible. Thus, how to refer to a particular declaration was
encoded into the Reference type _at the time of creation of the Reference_.
This commit refactors that logic and reduces Reference to a single class
with no subclasses. A Reference represents a node being referenced, plus
context about how the node was located. This context includes a
"bestGuessOwningModule", the compiler's best guess at which absolute
module specifier has defined this reference. For example, if the compiler
arrives at the declaration of CommonModule via an import to @angular/common,
then any references obtained from CommonModule (e.g. NgIf) will also be
considered to be owned by @angular/common.
A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface
are introduced. To produce an Expression referring to a given Reference'd
node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy
implementations.
Several different strategies are defined:
- LocalIdentifierStrategy: use local ts.Identifiers if available.
- AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule,
import the node via an absolute import from that module specifier.
- LogicalProjectStrategy: if the Reference is in the logical project
(is under the project rootDirs), import the node via a relative import.
- FileToModuleStrategy: use a FileToModuleHost to generate the module
specifier by which to import the node.
Depending on the availability of fileNameToModuleName in the CompilerHost,
then, a different collection of these strategies is used for compilation.
PR Close #28523
2019-02-01 17:24:21 -08:00
|
|
|
const evaluator = new PartialEvaluator(reflectionHost, checker);
|
feat(ivy): detect cycles and use remote scoping of components if needed (#28169)
By its nature, Ivy alters the import graph of a TS program, adding imports
where template dependencies exist. For example, if ComponentA uses PipeB
in its template, Ivy will insert an import of PipeB into the file in which
ComponentA is declared.
Any insertion of an import into a program has the potential to introduce a
cycle into the import graph. If for some reason the file in which PipeB is
declared imports the file in which ComponentA is declared (maybe it makes
use of a service or utility function that happens to be in the same file as
ComponentA) then this could create an import cycle. This turns out to
happen quite regularly in larger Angular codebases.
TypeScript and the Ivy runtime have no issues with such cycles. However,
other tools are not so accepting. In particular the Closure Compiler is
very anti-cycle.
To mitigate this problem, it's necessary to detect when the insertion of
an import would create a cycle. ngtsc can then use a different strategy,
known as "remote scoping", instead of directly writing a reference from
one component to another. Under remote scoping, a function
'setComponentScope' is called after the declaration of the component's
module, which does not require the addition of new imports.
FW-647 #resolve
PR Close #28169
2019-01-15 12:32:10 -08:00
|
|
|
const moduleResolver = new ModuleResolver(program, options, host);
|
|
|
|
|
const importGraph = new ImportGraph(moduleResolver);
|
|
|
|
|
const cycleAnalyzer = new CycleAnalyzer(importGraph);
|
2019-02-19 17:36:26 -08:00
|
|
|
const scopeRegistry = new LocalModuleScopeRegistry(
|
|
|
|
|
new MetadataDtsModuleScopeResolver(checker, reflectionHost, null), new ReferenceEmitter([]),
|
|
|
|
|
null);
|
2019-02-19 12:05:03 -08:00
|
|
|
const refEmitter = new ReferenceEmitter([]);
|
feat(ivy): detect cycles and use remote scoping of components if needed (#28169)
By its nature, Ivy alters the import graph of a TS program, adding imports
where template dependencies exist. For example, if ComponentA uses PipeB
in its template, Ivy will insert an import of PipeB into the file in which
ComponentA is declared.
Any insertion of an import into a program has the potential to introduce a
cycle into the import graph. If for some reason the file in which PipeB is
declared imports the file in which ComponentA is declared (maybe it makes
use of a service or utility function that happens to be in the same file as
ComponentA) then this could create an import cycle. This turns out to
happen quite regularly in larger Angular codebases.
TypeScript and the Ivy runtime have no issues with such cycles. However,
other tools are not so accepting. In particular the Closure Compiler is
very anti-cycle.
To mitigate this problem, it's necessary to detect when the insertion of
an import would create a cycle. ngtsc can then use a different strategy,
known as "remote scoping", instead of directly writing a reference from
one component to another. Under remote scoping, a function
'setComponentScope' is called after the declaration of the component's
module, which does not require the addition of new imports.
FW-647 #resolve
PR Close #28169
2019-01-15 12:32:10 -08:00
|
|
|
|
2018-08-23 14:34:55 -07:00
|
|
|
const handler = new ComponentDecoratorHandler(
|
2019-02-19 12:05:03 -08:00
|
|
|
reflectionHost, evaluator, scopeRegistry, false, new NoopResourceLoader(), [''], false,
|
|
|
|
|
true, moduleResolver, cycleAnalyzer, refEmitter);
|
2018-08-23 14:34:55 -07:00
|
|
|
const TestCmp = getDeclaration(program, 'entry.ts', 'TestCmp', ts.isClassDeclaration);
|
2018-12-18 11:09:21 -08:00
|
|
|
const detected = handler.detect(TestCmp, reflectionHost.getDecoratorsOfDeclaration(TestCmp));
|
2018-08-23 14:34:55 -07:00
|
|
|
if (detected === undefined) {
|
|
|
|
|
return fail('Failed to recognize @Component');
|
|
|
|
|
}
|
|
|
|
|
try {
|
feat(ivy): support @Injectable on already decorated classes (#28523)
Previously, ngtsc would throw an error if two decorators were matched on
the same class simultaneously. However, @Injectable is a special case, and
it appears frequently on component, directive, and pipe classes. For pipes
in particular, it's a common pattern to treat the pipe class also as an
injectable service.
ngtsc actually lacked the capability to compile multiple matching
decorators on a class, so this commit adds support for that. Decorator
handlers (and thus the decorators they match) are classified into three
categories: PRIMARY, SHARED, and WEAK.
PRIMARY handlers compile decorators that cannot coexist with other primary
decorators. The handlers for Component, Directive, Pipe, and NgModule are
marked as PRIMARY. A class may only have one decorator from this group.
SHARED handlers compile decorators that can coexist with others. Injectable
is the only decorator in this category, meaning it's valid to put an
@Injectable decorator on a previously decorated class.
WEAK handlers behave like SHARED, but are dropped if any non-WEAK handler
matches a class. The handler which compiles ngBaseDef is WEAK, since
ngBaseDef is only needed if a class doesn't otherwise have a decorator.
Tests are added to validate that @Injectable can coexist with the other
decorators and that an error is generated when mixing the primaries.
PR Close #28523
2019-02-01 12:23:21 -08:00
|
|
|
handler.analyze(TestCmp, detected.metadata);
|
2018-08-23 14:34:55 -07:00
|
|
|
return fail('Analysis should have failed');
|
|
|
|
|
} catch (err) {
|
|
|
|
|
if (!(err instanceof FatalDiagnosticError)) {
|
|
|
|
|
return fail('Error should be a FatalDiagnosticError');
|
|
|
|
|
}
|
|
|
|
|
const diag = err.toDiagnostic();
|
|
|
|
|
expect(diag.code).toEqual(ivyCode(ErrorCode.DECORATOR_ARG_NOT_LITERAL));
|
|
|
|
|
expect(diag.file.fileName.endsWith('entry.ts')).toBe(true);
|
feat(ivy): support @Injectable on already decorated classes (#28523)
Previously, ngtsc would throw an error if two decorators were matched on
the same class simultaneously. However, @Injectable is a special case, and
it appears frequently on component, directive, and pipe classes. For pipes
in particular, it's a common pattern to treat the pipe class also as an
injectable service.
ngtsc actually lacked the capability to compile multiple matching
decorators on a class, so this commit adds support for that. Decorator
handlers (and thus the decorators they match) are classified into three
categories: PRIMARY, SHARED, and WEAK.
PRIMARY handlers compile decorators that cannot coexist with other primary
decorators. The handlers for Component, Directive, Pipe, and NgModule are
marked as PRIMARY. A class may only have one decorator from this group.
SHARED handlers compile decorators that can coexist with others. Injectable
is the only decorator in this category, meaning it's valid to put an
@Injectable decorator on a previously decorated class.
WEAK handlers behave like SHARED, but are dropped if any non-WEAK handler
matches a class. The handler which compiles ngBaseDef is WEAK, since
ngBaseDef is only needed if a class doesn't otherwise have a decorator.
Tests are added to validate that @Injectable can coexist with the other
decorators and that an error is generated when mixing the primaries.
PR Close #28523
2019-02-01 12:23:21 -08:00
|
|
|
expect(diag.start).toBe(detected.metadata.args ![0].getStart());
|
2018-08-23 14:34:55 -07:00
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
function ivyCode(code: ErrorCode): number {
|
|
|
|
|
return Number('-99' + code.valueOf());
|
|
|
|
|
}
|