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
|
|
|
|
|
*/
|
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';
|
2019-06-06 20:22:32 +01:00
|
|
|
import {absoluteFrom} from '../../file_system';
|
|
|
|
|
import {runInEachFileSystem} from '../../file_system/testing';
|
fix(ivy): reuse default imports in type-to-value references (#29266)
This fixes an issue with commit b6f6b117. In this commit, default imports
processed in a type-to-value conversion were recorded as non-local imports
with a '*' name, and the ImportManager generated a new default import for
them. When transpiled to ES2015 modules, this resulted in the following
correct code:
import i3 from './module';
// somewhere in the file, a value reference of i3:
{type: i3}
However, when the AST with this synthetic import and reference was
transpiled to non-ES2015 modules (for example, to commonjs) an issue
appeared:
var module_1 = require('./module');
{type: i3}
TypeScript renames the imported identifier from i3 to module_1, but doesn't
substitute later references to i3. This is because the import and reference
are both synthetic, and never went through the TypeScript AST step of
"binding" which associates the reference to its import. This association is
important during emit when the identifiers might change.
Synthetic (transformer-added) imports will never be bound properly. The only
possible solution is to reuse the user's original import and the identifier
from it, which will be properly downleveled. The issue with this approach
(which prompted the fix in b6f6b117) is that if the import is only used in a
type position, TypeScript will mark it for deletion in the generated JS,
even though additional non-type usages are added in the transformer. This
again would leave a dangling import.
To work around this, it's necessary for the compiler to keep track of
identifiers that it emits which came from default imports, and tell TS not
to remove those imports during transpilation. A `DefaultImportTracker` class
is implemented to perform this tracking. It implements a
`DefaultImportRecorder` interface, which is used to record two significant
pieces of information:
* when a WrappedNodeExpr is generated which refers to a default imported
value, the ts.Identifier is associated to the ts.ImportDeclaration via
the recorder.
* when that WrappedNodeExpr is later emitted as part of the statement /
expression translators, the fact that the ts.Identifier was used is
also recorded.
Combined, this tracking gives the `DefaultImportTracker` enough information
to implement another TS transformer, which can recognize default imports
which were used in the output of the Ivy transform and can prevent them
from being elided. This is done by creating a new ts.ImportDeclaration for
the imports with the same ts.ImportClause. A test verifies that this works.
PR Close #29266
2019-03-11 16:54:07 -07:00
|
|
|
import {ModuleResolver, NOOP_DEFAULT_IMPORT_RECORDER, ReferenceEmitter} from '../../imports';
|
2019-04-01 14:20:34 -07:00
|
|
|
import {CompoundMetadataReader, DtsMetadataReader, LocalMetadataRegistry} from '../../metadata';
|
2018-12-18 09:48:15 -08:00
|
|
|
import {PartialEvaluator} from '../../partial_evaluator';
|
2019-03-20 12:10:58 +02:00
|
|
|
import {TypeScriptReflectionHost, isNamedClassDeclaration} from '../../reflection';
|
2019-02-19 12:05:03 -08:00
|
|
|
import {LocalModuleScopeRegistry, MetadataDtsModuleScopeResolver} from '../../scope';
|
2019-06-06 20:22:32 +01:00
|
|
|
import {getDeclaration, makeProgram} from '../../testing';
|
2018-08-23 14:34:55 -07:00
|
|
|
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
|
|
|
}
|
2019-06-06 20:22:32 +01:00
|
|
|
runInEachFileSystem(() => {
|
|
|
|
|
describe('ComponentDecoratorHandler', () => {
|
|
|
|
|
let _: typeof absoluteFrom;
|
|
|
|
|
beforeEach(() => _ = absoluteFrom);
|
2018-08-23 14:34:55 -07:00
|
|
|
|
2019-06-06 20:22:32 +01:00
|
|
|
it('should produce a diagnostic when @Component has non-literal argument', () => {
|
|
|
|
|
const {program, options, host} = makeProgram([
|
|
|
|
|
{
|
|
|
|
|
name: _('/node_modules/@angular/core/index.d.ts'),
|
|
|
|
|
contents: 'export const Component: any;',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: _('/entry.ts'),
|
|
|
|
|
contents: `
|
2018-08-23 14:34:55 -07:00
|
|
|
import {Component} from '@angular/core';
|
|
|
|
|
|
|
|
|
|
const TEST = '';
|
|
|
|
|
@Component(TEST) class TestCmp {}
|
|
|
|
|
`
|
2019-06-06 20:22:32 +01:00
|
|
|
},
|
|
|
|
|
]);
|
|
|
|
|
const checker = program.getTypeChecker();
|
|
|
|
|
const reflectionHost = new TypeScriptReflectionHost(checker);
|
perf(ivy): reuse prior analysis work during incremental builds (#34288)
Previously, the compiler performed an incremental build by analyzing and
resolving all classes in the program (even unchanged ones) and then using
the dependency graph information to determine which .js files were stale and
needed to be re-emitted. This algorithm produced "correct" rebuilds, but the
cost of re-analyzing the entire program turned out to be higher than
anticipated, especially for component-heavy compilations.
To achieve performant rebuilds, it is necessary to reuse previous analysis
results if possible. Doing this safely requires knowing when prior work is
viable and when it is stale and needs to be re-done.
The new algorithm implemented by this commit is such:
1) Each incremental build starts with knowledge of the last known good
dependency graph and analysis results from the last successful build,
plus of course information about the set of files changed.
2) The previous dependency graph's information is used to determine the
set of source files which have "logically" changed. A source file is
considered logically changed if it or any of its dependencies have
physically changed (on disk) since the last successful compilation. Any
logically unchanged dependencies have their dependency information copied
over to the new dependency graph.
3) During the `TraitCompiler`'s loop to consider all source files in the
program, if a source file is logically unchanged then its previous
analyses are "adopted" (and their 'register' steps are run). If the file
is logically changed, then it is re-analyzed as usual.
4) Then, incremental build proceeds as before, with the new dependency graph
being used to determine the set of files which require re-emitting.
This analysis reuse avoids template parsing operations in many circumstances
and significantly reduces the time it takes ngtsc to rebuild a large
application.
Future work will increase performance even more, by tackling a variety of
other opportunities to reuse or avoid work.
PR Close #34288
2019-12-05 16:03:17 -08:00
|
|
|
const evaluator = new PartialEvaluator(reflectionHost, checker, /* dependencyTracker */ null);
|
2019-12-07 22:38:36 +01:00
|
|
|
const moduleResolver =
|
|
|
|
|
new ModuleResolver(program, options, host, /* moduleResolutionCache */ null);
|
2019-06-06 20:22:32 +01:00
|
|
|
const importGraph = new ImportGraph(moduleResolver);
|
|
|
|
|
const cycleAnalyzer = new CycleAnalyzer(importGraph);
|
|
|
|
|
const metaRegistry = new LocalMetadataRegistry();
|
|
|
|
|
const dtsReader = new DtsMetadataReader(checker, reflectionHost);
|
|
|
|
|
const scopeRegistry = new LocalModuleScopeRegistry(
|
|
|
|
|
metaRegistry, new MetadataDtsModuleScopeResolver(dtsReader, null),
|
|
|
|
|
new ReferenceEmitter([]), null);
|
|
|
|
|
const metaReader = new CompoundMetadataReader([metaRegistry, dtsReader]);
|
|
|
|
|
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
|
|
|
|
2019-06-06 20:22:32 +01:00
|
|
|
const handler = new ComponentDecoratorHandler(
|
2019-11-05 18:00:55 -08:00
|
|
|
reflectionHost, evaluator, metaRegistry, metaReader, scopeRegistry, scopeRegistry,
|
|
|
|
|
/* isCore */ false, new NoopResourceLoader(), /* rootDirs */[''],
|
|
|
|
|
/* defaultPreserveWhitespaces */ false, /* i18nUseExternalIds */ true,
|
2019-12-03 08:36:38 +00:00
|
|
|
/* enableI18nLegacyMessageIdFormat */ false, moduleResolver, cycleAnalyzer, refEmitter,
|
perf(ivy): reuse prior analysis work during incremental builds (#34288)
Previously, the compiler performed an incremental build by analyzing and
resolving all classes in the program (even unchanged ones) and then using
the dependency graph information to determine which .js files were stale and
needed to be re-emitted. This algorithm produced "correct" rebuilds, but the
cost of re-analyzing the entire program turned out to be higher than
anticipated, especially for component-heavy compilations.
To achieve performant rebuilds, it is necessary to reuse previous analysis
results if possible. Doing this safely requires knowing when prior work is
viable and when it is stale and needs to be re-done.
The new algorithm implemented by this commit is such:
1) Each incremental build starts with knowledge of the last known good
dependency graph and analysis results from the last successful build,
plus of course information about the set of files changed.
2) The previous dependency graph's information is used to determine the
set of source files which have "logically" changed. A source file is
considered logically changed if it or any of its dependencies have
physically changed (on disk) since the last successful compilation. Any
logically unchanged dependencies have their dependency information copied
over to the new dependency graph.
3) During the `TraitCompiler`'s loop to consider all source files in the
program, if a source file is logically unchanged then its previous
analyses are "adopted" (and their 'register' steps are run). If the file
is logically changed, then it is re-analyzed as usual.
4) Then, incremental build proceeds as before, with the new dependency graph
being used to determine the set of files which require re-emitting.
This analysis reuse avoids template parsing operations in many circumstances
and significantly reduces the time it takes ngtsc to rebuild a large
application.
Future work will increase performance even more, by tackling a variety of
other opportunities to reuse or avoid work.
PR Close #34288
2019-12-05 16:03:17 -08:00
|
|
|
NOOP_DEFAULT_IMPORT_RECORDER, /* depTracker */ null,
|
|
|
|
|
/* annotateForClosureCompiler */ false);
|
2019-06-06 20:22:32 +01:00
|
|
|
const TestCmp = getDeclaration(program, _('/entry.ts'), 'TestCmp', isNamedClassDeclaration);
|
|
|
|
|
const detected = handler.detect(TestCmp, reflectionHost.getDecoratorsOfDeclaration(TestCmp));
|
|
|
|
|
if (detected === undefined) {
|
|
|
|
|
return fail('Failed to recognize @Component');
|
2018-08-23 14:34:55 -07:00
|
|
|
}
|
2019-06-06 20:22:32 +01:00
|
|
|
try {
|
|
|
|
|
handler.analyze(TestCmp, detected.metadata);
|
|
|
|
|
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);
|
|
|
|
|
expect(diag.start).toBe(detected.metadata.args ![0].getStart());
|
|
|
|
|
}
|
|
|
|
|
});
|
2018-08-23 14:34:55 -07:00
|
|
|
});
|
|
|
|
|
|
2019-06-06 20:22:32 +01:00
|
|
|
function ivyCode(code: ErrorCode): number { return Number('-99' + code.valueOf()); }
|
|
|
|
|
});
|