2019-11-13 13:52:49 -05:00
|
|
|
/**
|
|
|
|
* @license
|
2020-05-19 15:08:49 -04:00
|
|
|
* Copyright Google LLC All Rights Reserved.
|
2019-11-13 13:52:49 -05: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 {absoluteFrom} from '../../src/ngtsc/file_system';
|
|
|
|
import {runInEachFileSystem} from '../../src/ngtsc/file_system/testing';
|
2020-11-04 15:27:19 -05:00
|
|
|
import {loadStandardTestFiles} from '../../src/ngtsc/testing';
|
2019-11-13 13:52:49 -05:00
|
|
|
|
|
|
|
import {NgtscTestEnvironment} from './env';
|
|
|
|
|
|
|
|
const testFiles = loadStandardTestFiles();
|
|
|
|
|
|
|
|
runInEachFileSystem(() => {
|
|
|
|
describe('monorepos', () => {
|
2020-04-07 15:43:43 -04:00
|
|
|
let env!: NgtscTestEnvironment;
|
2019-11-13 13:52:49 -05:00
|
|
|
|
|
|
|
beforeEach(() => {
|
|
|
|
env = NgtscTestEnvironment.setup(testFiles, absoluteFrom('/app'));
|
|
|
|
env.tsconfig();
|
|
|
|
|
|
|
|
// env.tsconfig() will write to /app/tsconfig.json, but list it as extending
|
|
|
|
// ./tsconfig-base.json. So that file should exist, and redirect to ../tsconfig-base.json.
|
|
|
|
env.write('/app/tsconfig-base.json', JSON.stringify({'extends': '../tsconfig-base.json'}));
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should compile a project with a reference above the current dir', () => {
|
|
|
|
env.write('/app/index.ts', `
|
|
|
|
import {Component, NgModule} from '@angular/core';
|
|
|
|
import {LibModule} from '../lib/module';
|
|
|
|
|
|
|
|
@Component({
|
|
|
|
selector: 'app-cmp',
|
|
|
|
template: '<lib-cmp></lib-cmp>',
|
|
|
|
})
|
|
|
|
export class AppCmp {}
|
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
declarations: [AppCmp],
|
|
|
|
imports: [LibModule],
|
|
|
|
})
|
|
|
|
export class AppModule {}
|
|
|
|
`);
|
|
|
|
env.write('/lib/module.ts', `
|
|
|
|
import {NgModule} from '@angular/core';
|
|
|
|
import {LibCmp} from './cmp';
|
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
declarations: [LibCmp],
|
|
|
|
exports: [LibCmp],
|
|
|
|
})
|
|
|
|
export class LibModule {}
|
|
|
|
`);
|
|
|
|
env.write('/lib/cmp.ts', `
|
|
|
|
import {Component} from '@angular/core';
|
|
|
|
|
|
|
|
@Component({
|
|
|
|
selector: 'lib-cmp',
|
|
|
|
template: '...',
|
|
|
|
})
|
|
|
|
export class LibCmp {}
|
|
|
|
`);
|
|
|
|
|
|
|
|
env.driveMain();
|
|
|
|
|
|
|
|
const jsContents = env.getContents('app/index.js');
|
|
|
|
expect(jsContents).toContain(`import * as i1 from "../lib/cmp";`);
|
|
|
|
});
|
|
|
|
|
|
|
|
it('should compile a project with a reference into the same dir', () => {
|
|
|
|
env.write('/app/index.ts', `
|
|
|
|
import {Component, NgModule} from '@angular/core';
|
|
|
|
import {TargetModule} from './target';
|
|
|
|
|
|
|
|
@Component({
|
|
|
|
selector: 'app-cmp',
|
|
|
|
template: '<target-cmp></target-cmp>',
|
|
|
|
})
|
|
|
|
export class AppCmp {}
|
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
declarations: [AppCmp],
|
|
|
|
imports: [TargetModule],
|
|
|
|
})
|
|
|
|
export class AppModule {}
|
|
|
|
`);
|
|
|
|
|
|
|
|
env.write('/app/target.ts', `
|
|
|
|
import {Component, NgModule} from '@angular/core';
|
|
|
|
|
|
|
|
@Component({
|
|
|
|
selector: 'target-cmp',
|
|
|
|
template: '...',
|
|
|
|
})
|
|
|
|
export class TargetCmp {}
|
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
declarations: [TargetCmp],
|
|
|
|
exports: [TargetCmp],
|
|
|
|
})
|
|
|
|
export class TargetModule {}
|
|
|
|
`);
|
|
|
|
|
|
|
|
env.driveMain();
|
|
|
|
|
perf(compiler-cli): split Ivy template type-checking into multiple files (#36211)
As a performance optimization, this commit splits the single
__ngtypecheck__.ts file which was previously added to the user's program as
a container for all template type-checking code into multiple .ngtypecheck
shim files, one for each original file in the user's program.
In larger applications, the generation, parsing, and checking of this single
type-checking file was a huge performance bottleneck, with the file often
exceeding 1 MB in text content. Particularly in incremental builds,
regenerating this single file for the entire application proved especially
expensive.
This commit introduces a new strategy for template type-checking code which
makes use of a new interface, the `TypeCheckingProgramStrategy`. This
interface abstracts the process of creating a new `ts.Program` to type-check
a particular compilation, and allows the mechanism there to be kept separate
from the more complex logic around dealing with multiple .ngtypecheck files.
A new `TemplateTypeChecker` hosts that logic and interacts with the
`TypeCheckingProgramStrategy` to actually generate and return diagnostics.
The `TypeCheckContext` class, previously the workhorse of template type-
checking, is now solely focused on collecting and generating type-checking
file contents.
A side effect of implementing the new `TypeCheckingProgramStrategy` in this
way is that the API is designed to be suitable for use by the Angular
Language Service as well. The LS also needs to type-check components, but
has its own method for constructing a `ts.Program` with type-checking code.
Note that this commit does not make the actual checking of templates at all
_incremental_ just yet. That will happen in a future commit.
PR Close #36211
2020-03-04 18:50:12 -05:00
|
|
|
const jsContents = env.getContents('app/index.js');
|
2019-11-13 13:52:49 -05:00
|
|
|
|
perf(compiler-cli): split Ivy template type-checking into multiple files (#36211)
As a performance optimization, this commit splits the single
__ngtypecheck__.ts file which was previously added to the user's program as
a container for all template type-checking code into multiple .ngtypecheck
shim files, one for each original file in the user's program.
In larger applications, the generation, parsing, and checking of this single
type-checking file was a huge performance bottleneck, with the file often
exceeding 1 MB in text content. Particularly in incremental builds,
regenerating this single file for the entire application proved especially
expensive.
This commit introduces a new strategy for template type-checking code which
makes use of a new interface, the `TypeCheckingProgramStrategy`. This
interface abstracts the process of creating a new `ts.Program` to type-check
a particular compilation, and allows the mechanism there to be kept separate
from the more complex logic around dealing with multiple .ngtypecheck files.
A new `TemplateTypeChecker` hosts that logic and interacts with the
`TypeCheckingProgramStrategy` to actually generate and return diagnostics.
The `TypeCheckContext` class, previously the workhorse of template type-
checking, is now solely focused on collecting and generating type-checking
file contents.
A side effect of implementing the new `TypeCheckingProgramStrategy` in this
way is that the API is designed to be suitable for use by the Angular
Language Service as well. The LS also needs to type-check components, but
has its own method for constructing a `ts.Program` with type-checking code.
Note that this commit does not make the actual checking of templates at all
_incremental_ just yet. That will happen in a future commit.
PR Close #36211
2020-03-04 18:50:12 -05:00
|
|
|
// Check that the relative import has the leading './'.
|
2019-11-13 13:52:49 -05:00
|
|
|
expect(jsContents).toContain(`import * as i1 from "./target";`);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
});
|