iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/packages/compiler-cli/ngcc/test/dependencies/dependency_resolver_spec.ts

508 lines
25 KiB
TypeScript
Raw Normal View History

fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
/**
* @license
build: update license headers to reference Google LLC (#37205) Update the license headers throughout the repository to reference Google LLC rather than Google Inc, for the required license headers. PR Close #37205
2020-05-19 15:08:49 -04:00
* Copyright Google LLC All Rights Reserved.
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04: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
*/
perf(ngcc): process tasks in parallel in async mode (#32427) `ngcc` supports both synchronous and asynchronous execution. The default mode when using `ngcc` programmatically (which is how `@angular/cli` is using it) is synchronous. When running `ngcc` from the command line (i.e. via the `ivy-ngcc` script), it runs in async mode. Previously, the work would be executed in the same way in both modes. This commit improves the performance of `ngcc` in async mode by processing tasks in parallel on multiple processes. It uses the Node.js built-in [`cluster` module](https://nodejs.org/api/cluster.html) to launch a cluster of Node.js processes and take advantage of multi-core systems. Preliminary comparisons indicate a 1.8x to 2.6x speed improvement when processing the angular.io app (apparently depending on the OS, number of available cores, system load, etc.). Further investigation is needed to better understand these numbers and identify potential areas of improvement. Inspired by/Based on @alxhub's prototype: alxhub/angular@cb631bdb1 Original design doc: https://hackmd.io/uYG9CJrFQZ-6FtKqpnYJAA?view Jira issue: [FW-1460](https://angular-team.atlassian.net/browse/FW-1460) PR Close #32427
2019-08-29 11:47:54 -04:00
import {DepGraph} from 'dependency-graph';
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
import {absoluteFrom, AbsoluteFsPath, FileSystem, getFileSystem, relativeFrom} from '../../../src/ngtsc/file_system';
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
import {runInEachFileSystem} from '../../../src/ngtsc/file_system/testing';
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
import {DependencyInfo, EntryPointWithDependencies} from '../../src/dependencies/dependency_host';
refactor(ivy): ngcc - move the dependency resolving stuff around (#29643) For UMD/RequireJS support we will need to have multiple `DependencyHost` implementations. This commit prepares the ground for that. PR Close #29643
2019-04-28 15:47:57 -04:00
import {DependencyResolver, SortedEntryPointsInfo} from '../../src/dependencies/dependency_resolver';
fix(ngcc): avoid error due to circular dependency in `EsmDependencyHost` (#34512) Previously, there was circular dependency between `ngcc/src/utils.ts`, `ngcc/src/dependencies/dependency_host.ts` and `ngcc/src/dependencies/esm_dependency_host.ts`. More specifically, `utils.ts` would [import from `esm_dependency_host.ts`][1], which would [import from `dependency_host.ts`][2], which would in turn [import from `utils.ts`][3]. This might be fine in some environments/module formats, but it can cause unclear errors in the transpiled CommonJS/UMD format (given how Node.js handles [cycles in module resolution][4]). (An example error can be found [here][5].) This commit fixes the problem by moving the code that depends on `EsmDependencyHost` out of `utils.ts` and into a dedicated file under `dependencies/`. It also converts the `createDtsDependencyHost()` function to a class for consistency with the rest of the `DependencyHost`s. [1]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/utils.ts#L10 [2]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/esm_dependency_host.ts#L10 [3]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/dependency_host.ts#L9 [4]: https://nodejs.org/api/modules.html#modules_cycles [5]: https://circleci.com/gh/angular/angular/577581 PR Close #34512
2020-01-08 12:10:25 -05:00
import {DtsDependencyHost} from '../../src/dependencies/dts_dependency_host';
refactor(ivy): ngcc - move the dependency resolving stuff around (#29643) For UMD/RequireJS support we will need to have multiple `DependencyHost` implementations. This commit prepares the ground for that. PR Close #29643
2019-04-28 15:47:57 -04:00
import {EsmDependencyHost} from '../../src/dependencies/esm_dependency_host';
import {ModuleResolver} from '../../src/dependencies/module_resolver';
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
import {NgccConfiguration} from '../../src/packages/configuration';
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
import {EntryPoint} from '../../src/packages/entry_point';
feat(compiler-cli): ngcc - make logging more configurable (#29591) This allows CLI usage to filter excessive log messages and integrations like webpack plugins to provide their own logger. // FW-1198 PR Close #29591
2019-03-29 06:13:14 -04:00
import {MockLogger} from '../helpers/mock_logger';
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
perf(ngcc): process tasks in parallel in async mode (#32427) `ngcc` supports both synchronous and asynchronous execution. The default mode when using `ngcc` programmatically (which is how `@angular/cli` is using it) is synchronous. When running `ngcc` from the command line (i.e. via the `ivy-ngcc` script), it runs in async mode. Previously, the work would be executed in the same way in both modes. This commit improves the performance of `ngcc` in async mode by processing tasks in parallel on multiple processes. It uses the Node.js built-in [`cluster` module](https://nodejs.org/api/cluster.html) to launch a cluster of Node.js processes and take advantage of multi-core systems. Preliminary comparisons indicate a 1.8x to 2.6x speed improvement when processing the angular.io app (apparently depending on the OS, number of available cores, system load, etc.). Further investigation is needed to better understand these numbers and identify potential areas of improvement. Inspired by/Based on @alxhub's prototype: alxhub/angular@cb631bdb1 Original design doc: https://hackmd.io/uYG9CJrFQZ-6FtKqpnYJAA?view Jira issue: [FW-1460](https://angular-team.atlassian.net/browse/FW-1460) PR Close #32427
2019-08-29 11:47:54 -04:00
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
interface DepMap {
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
[path: string]: {resolved: string[], missing: string[], deepImports?: AbsoluteFsPath[]};
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
}
runInEachFileSystem(() => {
describe('DependencyResolver', () => {
let _: typeof absoluteFrom;
let host: EsmDependencyHost;
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
let dtsHost: EsmDependencyHost;
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
let resolver: DependencyResolver;
let fs: FileSystem;
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
let config: NgccConfiguration;
let logger: MockLogger;
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
let moduleResolver: ModuleResolver;
beforeEach(() => {
_ = absoluteFrom;
fs = getFileSystem();
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
config = new NgccConfiguration(fs, _('/'));
logger = new MockLogger();
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
moduleResolver = new ModuleResolver(fs);
host = new EsmDependencyHost(fs, moduleResolver);
fix(ngcc): avoid error due to circular dependency in `EsmDependencyHost` (#34512) Previously, there was circular dependency between `ngcc/src/utils.ts`, `ngcc/src/dependencies/dependency_host.ts` and `ngcc/src/dependencies/esm_dependency_host.ts`. More specifically, `utils.ts` would [import from `esm_dependency_host.ts`][1], which would [import from `dependency_host.ts`][2], which would in turn [import from `utils.ts`][3]. This might be fine in some environments/module formats, but it can cause unclear errors in the transpiled CommonJS/UMD format (given how Node.js handles [cycles in module resolution][4]). (An example error can be found [here][5].) This commit fixes the problem by moving the code that depends on `EsmDependencyHost` out of `utils.ts` and into a dedicated file under `dependencies/`. It also converts the `createDtsDependencyHost()` function to a class for consistency with the rest of the `DependencyHost`s. [1]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/utils.ts#L10 [2]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/esm_dependency_host.ts#L10 [3]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/dependency_host.ts#L9 [4]: https://nodejs.org/api/modules.html#modules_cycles [5]: https://circleci.com/gh/angular/angular/577581 PR Close #34512
2020-01-08 12:10:25 -05:00
dtsHost = new DtsDependencyHost(fs);
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
resolver = new DependencyResolver(fs, logger, config, {esm5: host, esm2015: host}, dtsHost);
feat(ivy): ngcc - support targeting a start entry-point (#29092) You can now, programmatically, specify an entry-point where the ngcc compilation will occur. Only this entry-point and its dependencies will be compiled. FW-1119 PR Close #29092
2019-03-20 09:47:58 -04:00
});
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
describe('sortEntryPointsByDependency()', () => {
let first: EntryPoint;
let second: EntryPoint;
let third: EntryPoint;
let fourth: EntryPoint;
let fifth: EntryPoint;
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
let sixthIgnoreMissing: EntryPoint;
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
let dependencies: DepMap;
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
let dtsDependencies: DepMap;
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
beforeEach(() => {
first = {
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
name: 'first',
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
path: _('/first'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'first',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/first'),
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
packageJson: {esm5: './index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/first/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: false,
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
} as EntryPoint;
second = {
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
name: 'second',
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
path: _('/second'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'second',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/second'),
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
packageJson: {esm2015: './sub/index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/second/sub/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: false,
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
} as EntryPoint;
third = {
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
name: 'third',
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
path: _('/third'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'third',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/third'),
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
packageJson: {fesm5: './index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/third/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: false,
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
} as EntryPoint;
fourth = {
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
name: 'fourth',
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
path: _('/fourth'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'fourth',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/fourth'),
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
packageJson: {fesm2015: './sub2/index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/fourth/sub2/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: false,
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
} as EntryPoint;
fifth = {
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
name: 'fifth',
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
path: _('/fifth'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'fifth',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/fifth'),
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
packageJson: {module: './index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/fifth/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: false,
} as EntryPoint;
sixthIgnoreMissing = {
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
name: 'sixth',
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
path: _('/sixth'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'sixth',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/sixth'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
packageJson: {module: './index.js'},
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
typings: _('/sixth/index.d.ts'),
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
compiledByAngular: true,
ignoreMissingDependencies: true,
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
} as EntryPoint;
dependencies = {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
[_('/first/index.js')]:
{resolved: [second.path, third.path, _('/ignored-1')], missing: []},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/second/sub/index.js')]: {resolved: [third.path, fifth.path], missing: []},
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
[_('/third/index.js')]: {resolved: [fourth.path, _('/ignored-2')], missing: []},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/fourth/sub2/index.js')]: {resolved: [fifth.path], missing: []},
[_('/fifth/index.js')]: {resolved: [], missing: []},
};
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
dtsDependencies = {
[_('/first/index.d.ts')]:
{resolved: [second.path, third.path, _('/ignored-1')], missing: []},
[_('/second/sub/index.d.ts')]: {resolved: [third.path, fifth.path], missing: []},
[_('/third/index.d.ts')]: {resolved: [fourth.path, _('/ignored-2')], missing: []},
[_('/fourth/sub2/index.d.ts')]: {resolved: [fifth.path], missing: []},
[_('/fifth/index.d.ts')]: {resolved: [], missing: []},
};
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
});
it('should order the entry points by their dependency on each other', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dependencies));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dtsDependencies));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [fifth, first, fourth, second, third]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.entryPoints).toEqual([fifth, fourth, third, second, first]);
});
it('should remove entry-points that have missing direct dependencies', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/second/sub/index.js')]: {resolved: [], missing: []},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
[_('/second/sub/index.d.ts')]: {resolved: [], missing: []},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result =
resolver.sortEntryPointsByDependency(getEntryPointsWithDeps(resolver, [first, second]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.entryPoints).toEqual([second]);
expect(result.invalidEntryPoints).toEqual([
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
{entryPoint: first, missingDependencies: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
]);
});
it('should remove entry points that depended upon an invalid entry-point', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/first/index.js')]: {resolved: [second.path, third.path], missing: []},
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
[_('/second/sub/index.js')]: {resolved: [], missing: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/third/index.js')]: {resolved: [], missing: []},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [second.path, third.path], missing: []},
[_('/second/sub/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
[_('/third/index.d.ts')]: {resolved: [], missing: []},
}));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
// Note that we will process `first` before `second`, which has the missing dependency.
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [first, second, third]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.entryPoints).toEqual([third]);
expect(result.invalidEntryPoints).toEqual([
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
{entryPoint: second, missingDependencies: [_('/missing')]},
{entryPoint: first, missingDependencies: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
]);
});
it('should remove entry points that will depend upon an invalid entry-point', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/first/index.js')]: {resolved: [second.path, third.path], missing: []},
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
[_('/second/sub/index.js')]: {resolved: [], missing: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
[_('/third/index.js')]: {resolved: [], missing: []},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [second.path, third.path], missing: []},
[_('/second/sub/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
[_('/third/index.d.ts')]: {resolved: [], missing: []},
}));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
// Note that we will process `first` after `second`, which has the missing dependency.
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [second, first, third]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.entryPoints).toEqual([third]);
expect(result.invalidEntryPoints).toEqual([
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
{entryPoint: second, missingDependencies: [_('/missing')]},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
{entryPoint: first, missingDependencies: [second.path]},
]);
});
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
it('should cope with entry points that will depend upon an invalid entry-point, when told to ignore missing dependencies',
() => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
[_('/first/index.js')]: {resolved: [sixthIgnoreMissing.path], missing: []},
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
[_('/sixth/index.js')]: {resolved: [], missing: [_('/missing')]},
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [sixthIgnoreMissing.path], missing: []},
[_('/sixth/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
}));
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
// Note that we will process `first` after `second`, which has the missing dependency.
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [sixthIgnoreMissing, first]));
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
expect(result.entryPoints).toEqual([sixthIgnoreMissing, first]);
expect(result.invalidEntryPoints).toEqual([]);
});
it('should not transitively ignore missing dependencies', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: [_('/missing')]},
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
[_('/second/sub/index.js')]: {resolved: [first.path], missing: []},
[_('/sixth/index.js')]: {resolved: [second.path], missing: []},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
[_('/second/sub/index.d.ts')]: {resolved: [first.path], missing: []},
[_('/sixth/index.d.ts')]: {resolved: [second.path], missing: []},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [first, second, sixthIgnoreMissing]));
feat(ngcc): support ignoreMissingDependencies in ngcc config (#33192) Normally, when ngcc encounters a package with missing dependencies while attempting to determine a compilation ordering, it will ignore that package. This commit adds a configuration for a flag to tell ngcc to compile the package anyway, regardless of any missing dependencies. FW-1931 #resolve PR Close #33192
2019-10-02 03:32:57 -04:00
// sixth has no missing dependencies, but it has _invalid_ dependencies, so it's not
// compiled.
expect(result.entryPoints).toEqual([]);
});
fix(ivy): ngcc - don't crash if entry-points have multiple invalid dependencies (#31276) If an entry-point has missing dependencies then it cannot be processed and is marked as invalid. Similarly, if an entry-point has dependencies that have been marked as invalid then that entry-point too is invalid. In all these cases, ngcc should quietly ignore these entry-points and continue processing what it can. Previously, if an entry-point had more than one entry-point that was transitively invalid then ngcc was crashing rather than ignoring the entry-point. PR Close #31276
2019-06-26 04:16:15 -04:00
it('should cope with entry points having multiple indirect missing dependencies', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: [_('/missing1')]},
[_('/second/sub/index.js')]: {resolved: [], missing: [_('/missing2')]},
fix(ivy): ngcc - don't crash if entry-points have multiple invalid dependencies (#31276) If an entry-point has missing dependencies then it cannot be processed and is marked as invalid. Similarly, if an entry-point has dependencies that have been marked as invalid then that entry-point too is invalid. In all these cases, ngcc should quietly ignore these entry-points and continue processing what it can. Previously, if an entry-point had more than one entry-point that was transitively invalid then ngcc was crashing rather than ignoring the entry-point. PR Close #31276
2019-06-26 04:16:15 -04:00
[_('/third/index.js')]: {resolved: [first.path, second.path], missing: []},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: [_('/missing1')]},
[_('/second/sub/index.d.ts')]: {resolved: [], missing: [_('/missing2')]},
[_('/third/index.d.ts')]: {resolved: [first.path, second.path], missing: []},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [first, second, third]));
fix(ivy): ngcc - don't crash if entry-points have multiple invalid dependencies (#31276) If an entry-point has missing dependencies then it cannot be processed and is marked as invalid. Similarly, if an entry-point has dependencies that have been marked as invalid then that entry-point too is invalid. In all these cases, ngcc should quietly ignore these entry-points and continue processing what it can. Previously, if an entry-point had more than one entry-point that was transitively invalid then ngcc was crashing rather than ignoring the entry-point. PR Close #31276
2019-06-26 04:16:15 -04:00
expect(result.entryPoints).toEqual([]);
expect(result.invalidEntryPoints).toEqual([
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
{entryPoint: first, missingDependencies: [_('/missing1')]},
{entryPoint: second, missingDependencies: [_('/missing2')]},
fix(ivy): ngcc - don't crash if entry-points have multiple invalid dependencies (#31276) If an entry-point has missing dependencies then it cannot be processed and is marked as invalid. Similarly, if an entry-point has dependencies that have been marked as invalid then that entry-point too is invalid. In all these cases, ngcc should quietly ignore these entry-points and continue processing what it can. Previously, if an entry-point had more than one entry-point that was transitively invalid then ngcc was crashing rather than ignoring the entry-point. PR Close #31276
2019-06-26 04:16:15 -04:00
{entryPoint: third, missingDependencies: [first.path]},
]);
});
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
it('should log a warning for deep imports', () => {
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: [], deepImports: [_('/deep/one')]},
}));
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: []},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result =
resolver.sortEntryPointsByDependency(getEntryPointsWithDeps(resolver, [first]));
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
expect(result.entryPoints).toEqual([first]);
expect(logger.logs.warn).toEqual([[
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
`Entry point 'first' contains deep imports into '${
_('/deep/one')}'. This is probably not a problem, but may cause the compilation of entry points to be out of order.`
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
]]);
});
it('should not log a warning for ignored deep imports', () => {
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
fix(ngcc): correctly get config for packages in nested `node_modules/` (#37040) Previously, ngcc would only be able to match an ngcc configuration to packages that were located inside the project's top-level `node_modules/`. However, if there are multiple versions of a package in a project (e.g. as a transitive dependency of other packages), multiple copies of a package (at different versions) may exist in nested `node_modules/` directories. For example, one at `<project-root>/node_modules/some-package/` and one at `<project-root>/node_modules/other-package/node_modules/some-package/`. In such cases, ngcc was only able to detect the config for the first copy but not for the second. This commit fixes this by returning a new instance of `ProcessedNgccPackageConfig` for each different package path (even if they refer to the same package name). In these `ProcessedNgccPackageConfig`, the `entryPoints` paths have been processed to take the package path into account. PR Close #37040
2020-06-08 15:04:38 -04:00
[_('/project/node_modules/test-package/test-entry-point/index.js')]: {
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
resolved: [],
missing: [],
deepImports: [
_('/project/node_modules/deep/one'), _('/project/node_modules/deep/two'),
_('/project/node_modules/deeper/one'), _('/project/node_modules/deeper/two')
]
},
}));
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
fix(ngcc): correctly get config for packages in nested `node_modules/` (#37040) Previously, ngcc would only be able to match an ngcc configuration to packages that were located inside the project's top-level `node_modules/`. However, if there are multiple versions of a package in a project (e.g. as a transitive dependency of other packages), multiple copies of a package (at different versions) may exist in nested `node_modules/` directories. For example, one at `<project-root>/node_modules/some-package/` and one at `<project-root>/node_modules/other-package/node_modules/some-package/`. In such cases, ngcc was only able to detect the config for the first copy but not for the second. This commit fixes this by returning a new instance of `ProcessedNgccPackageConfig` for each different package path (even if they refer to the same package name). In these `ProcessedNgccPackageConfig`, the `entryPoints` paths have been processed to take the package path into account. PR Close #37040
2020-06-08 15:04:38 -04:00
[_('/project/node_modules/test-package/test-entry-point/index.d.ts')]: {
resolved: [],
missing: [],
},
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
}));
// Setup the configuration to ignore deep imports that contain either "deep/" or "two".
fs.ensureDir(_('/project'));
fs.writeFile(
_('/project/ngcc.config.js'),
`module.exports = { packages: { 'test-package': { ignorableDeepImportMatchers: [/deep\\//, /two/] } } };`);
config = new NgccConfiguration(fs, _('/project'));
resolver = new DependencyResolver(fs, logger, config, {esm5: host, esm2015: host}, dtsHost);
const testEntryPoint = {
fix(ngcc): correctly get config for packages in nested `node_modules/` (#37040) Previously, ngcc would only be able to match an ngcc configuration to packages that were located inside the project's top-level `node_modules/`. However, if there are multiple versions of a package in a project (e.g. as a transitive dependency of other packages), multiple copies of a package (at different versions) may exist in nested `node_modules/` directories. For example, one at `<project-root>/node_modules/some-package/` and one at `<project-root>/node_modules/other-package/node_modules/some-package/`. In such cases, ngcc was only able to detect the config for the first copy but not for the second. This commit fixes this by returning a new instance of `ProcessedNgccPackageConfig` for each different package path (even if they refer to the same package name). In these `ProcessedNgccPackageConfig`, the `entryPoints` paths have been processed to take the package path into account. PR Close #37040
2020-06-08 15:04:38 -04:00
name: 'test-package/test-entry-point',
path: _('/project/node_modules/test-package/test-entry-point'),
refactor(ngcc): add `packageName` property to `EntryPoint` interface (#37040) This commit adds a `packageName` property to the `EntryPoint` interface. In a subsequent commit this will be used to retrieve the correct ngcc configuration for each package, regardless of its path. PR Close #37040
2020-06-08 15:04:35 -04:00
packageName: 'test-package',
refactor(ngcc): rename `EntryPoint#package` to `EntryPoint#packagePath` (#37040) Rename the `package` property to `packagePath` on the `EntryPoint` interface. This makes it more clear that the `packagePath` property holds the absolute path to the containing package (similar to how `path` holds the path to the entry-point). This will also align with the `packageName` property that will be added in a subsequent commit. This commit also re-orders the `EntryPoint` properties to group related properties together and to match the order of properties on instances with that on the interface. PR Close #37040
2020-06-08 15:04:28 -04:00
packagePath: _('/project/node_modules/test-package'),
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
packageJson: {esm5: './index.js'},
fix(ngcc): correctly get config for packages in nested `node_modules/` (#37040) Previously, ngcc would only be able to match an ngcc configuration to packages that were located inside the project's top-level `node_modules/`. However, if there are multiple versions of a package in a project (e.g. as a transitive dependency of other packages), multiple copies of a package (at different versions) may exist in nested `node_modules/` directories. For example, one at `<project-root>/node_modules/some-package/` and one at `<project-root>/node_modules/other-package/node_modules/some-package/`. In such cases, ngcc was only able to detect the config for the first copy but not for the second. This commit fixes this by returning a new instance of `ProcessedNgccPackageConfig` for each different package path (even if they refer to the same package name). In these `ProcessedNgccPackageConfig`, the `entryPoints` paths have been processed to take the package path into account. PR Close #37040
2020-06-08 15:04:38 -04:00
typings: _('/project/node_modules/test-package/test-entry-point/index.d.ts'),
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
compiledByAngular: true,
ignoreMissingDependencies: false,
} as EntryPoint;
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [testEntryPoint]));
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
expect(result.entryPoints).toEqual([testEntryPoint]);
expect(logger.logs.warn).toEqual([[
fix(ngcc): correctly get config for packages in nested `node_modules/` (#37040) Previously, ngcc would only be able to match an ngcc configuration to packages that were located inside the project's top-level `node_modules/`. However, if there are multiple versions of a package in a project (e.g. as a transitive dependency of other packages), multiple copies of a package (at different versions) may exist in nested `node_modules/` directories. For example, one at `<project-root>/node_modules/some-package/` and one at `<project-root>/node_modules/other-package/node_modules/some-package/`. In such cases, ngcc was only able to detect the config for the first copy but not for the second. This commit fixes this by returning a new instance of `ProcessedNgccPackageConfig` for each different package path (even if they refer to the same package name). In these `ProcessedNgccPackageConfig`, the `entryPoints` paths have been processed to take the package path into account. PR Close #37040
2020-06-08 15:04:38 -04:00
`Entry point 'test-package/test-entry-point' contains deep imports into '${
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
_('/project/node_modules/deeper/one')}'. This is probably not a problem, but may cause the compilation of entry points to be out of order.`
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
]]);
});
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
it('should error if the entry point does not have a suitable format', () => {
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
expect(() => resolver.sortEntryPointsByDependency(getEntryPointsWithDeps(resolver, [
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
{path: '/first', packageJson: {}, compiledByAngular: true} as EntryPoint
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
]))).toThrowError(`There is no appropriate source code format in '/first' entry-point.`);
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
});
it('should error if there is no appropriate DependencyHost for the given formats', () => {
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
resolver = new DependencyResolver(fs, new MockLogger(), config, {esm2015: host}, host);
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
expect(
() => resolver.sortEntryPointsByDependency(getEntryPointsWithDeps(resolver, [first])))
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
.toThrowError(
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
`Could not find a suitable format for computing dependencies of entry-point: '${
first.path}'.`);
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
});
it('should capture any dependencies that were ignored', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dependencies));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dtsDependencies));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [fifth, first, fourth, second, third]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.ignoredDependencies).toEqual([
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
{entryPoint: first, dependencyPath: _('/ignored-1')},
{entryPoint: third, dependencyPath: _('/ignored-2')},
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
]);
});
perf(ngcc): process tasks in parallel in async mode (#32427) `ngcc` supports both synchronous and asynchronous execution. The default mode when using `ngcc` programmatically (which is how `@angular/cli` is using it) is synchronous. When running `ngcc` from the command line (i.e. via the `ivy-ngcc` script), it runs in async mode. Previously, the work would be executed in the same way in both modes. This commit improves the performance of `ngcc` in async mode by processing tasks in parallel on multiple processes. It uses the Node.js built-in [`cluster` module](https://nodejs.org/api/cluster.html) to launch a cluster of Node.js processes and take advantage of multi-core systems. Preliminary comparisons indicate a 1.8x to 2.6x speed improvement when processing the angular.io app (apparently depending on the OS, number of available cores, system load, etc.). Further investigation is needed to better understand these numbers and identify potential areas of improvement. Inspired by/Based on @alxhub's prototype: alxhub/angular@cb631bdb1 Original design doc: https://hackmd.io/uYG9CJrFQZ-6FtKqpnYJAA?view Jira issue: [FW-1460](https://angular-team.atlassian.net/browse/FW-1460) PR Close #32427
2019-08-29 11:47:54 -04:00
it('should return the computed dependency graph', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dependencies));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dtsDependencies));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [fifth, first, fourth, second, third]));
perf(ngcc): process tasks in parallel in async mode (#32427) `ngcc` supports both synchronous and asynchronous execution. The default mode when using `ngcc` programmatically (which is how `@angular/cli` is using it) is synchronous. When running `ngcc` from the command line (i.e. via the `ivy-ngcc` script), it runs in async mode. Previously, the work would be executed in the same way in both modes. This commit improves the performance of `ngcc` in async mode by processing tasks in parallel on multiple processes. It uses the Node.js built-in [`cluster` module](https://nodejs.org/api/cluster.html) to launch a cluster of Node.js processes and take advantage of multi-core systems. Preliminary comparisons indicate a 1.8x to 2.6x speed improvement when processing the angular.io app (apparently depending on the OS, number of available cores, system load, etc.). Further investigation is needed to better understand these numbers and identify potential areas of improvement. Inspired by/Based on @alxhub's prototype: alxhub/angular@cb631bdb1 Original design doc: https://hackmd.io/uYG9CJrFQZ-6FtKqpnYJAA?view Jira issue: [FW-1460](https://angular-team.atlassian.net/browse/FW-1460) PR Close #32427
2019-08-29 11:47:54 -04:00
expect(result.graph).toEqual(jasmine.any(DepGraph));
expect(result.graph.size()).toBe(5);
expect(result.graph.dependenciesOf(third.path)).toEqual([fifth.path, fourth.path]);
});
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
it('should only return dependencies of the target, if provided', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dependencies));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dtsDependencies));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const entryPoints = getEntryPointsWithDeps(resolver, [fifth, first, fourth, second, third]);
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
let sorted: SortedEntryPointsInfo;
sorted = resolver.sortEntryPointsByDependency(entryPoints, first);
expect(sorted.entryPoints).toEqual([fifth, fourth, third, second, first]);
sorted = resolver.sortEntryPointsByDependency(entryPoints, second);
expect(sorted.entryPoints).toEqual([fifth, fourth, third, second]);
sorted = resolver.sortEntryPointsByDependency(entryPoints, third);
expect(sorted.entryPoints).toEqual([fifth, fourth, third]);
sorted = resolver.sortEntryPointsByDependency(entryPoints, fourth);
expect(sorted.entryPoints).toEqual([fifth, fourth]);
sorted = resolver.sortEntryPointsByDependency(entryPoints, fifth);
expect(sorted.entryPoints).toEqual([fifth]);
});
fix(ivy): ngcc - prevent crash when analyzed target is ignored (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. When a target entrypoint to compile is provided, it could occur that given target is considered ignored because one of its dependencies might be missing. This situation was not dealt with currently, instead resulting in a crash of ngcc. This commit prevents the crash by taking the above scenario into account. PR Close #31872
2019-07-27 15:02:04 -04:00
it('should not process the provided target if it has missing dependencies', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: [_('/missing')]},
fix(ivy): ngcc - prevent crash when analyzed target is ignored (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. When a target entrypoint to compile is provided, it could occur that given target is considered ignored because one of its dependencies might be missing. This situation was not dealt with currently, instead resulting in a crash of ngcc. This commit prevents the crash by taking the above scenario into account. PR Close #31872
2019-07-27 15:02:04 -04:00
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: [_('/missing')]},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const entryPoints = getEntryPointsWithDeps(resolver, [first]);
fix(ivy): ngcc - prevent crash when analyzed target is ignored (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. When a target entrypoint to compile is provided, it could occur that given target is considered ignored because one of its dependencies might be missing. This situation was not dealt with currently, instead resulting in a crash of ngcc. This commit prevents the crash by taking the above scenario into account. PR Close #31872
2019-07-27 15:02:04 -04:00
let sorted: SortedEntryPointsInfo;
sorted = resolver.sortEntryPointsByDependency(entryPoints, first);
expect(sorted.entryPoints).toEqual([]);
expect(sorted.invalidEntryPoints[0].entryPoint).toEqual(first);
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
expect(sorted.invalidEntryPoints[0].missingDependencies).toEqual([_('/missing')]);
fix(ivy): ngcc - prevent crash when analyzed target is ignored (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. When a target entrypoint to compile is provided, it could occur that given target is considered ignored because one of its dependencies might be missing. This situation was not dealt with currently, instead resulting in a crash of ngcc. This commit prevents the crash by taking the above scenario into account. PR Close #31872
2019-07-27 15:02:04 -04:00
});
fix(ivy): ngcc - do not consider builtin NodeJS modules as missing (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. For libraries that work with Angular Universal to run in NodeJS, imports into builtin NodeJS modules can be present. ngcc's dependency analyzer can only resolve imports within the TypeScript compilation, which builtin modules are not part of. Therefore, such imports would erroneously cause the entrypoint to become ignored. This commit fixes the problem by taking the NodeJS builtins into account when dealing with missing imports. Fixes #31522 PR Close #31872
2019-07-27 15:37:04 -04:00
it('should not consider builtin NodeJS modules as missing dependency', () => {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
fix(ivy): ngcc - do not consider builtin NodeJS modules as missing (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. For libraries that work with Angular Universal to run in NodeJS, imports into builtin NodeJS modules can be present. ngcc's dependency analyzer can only resolve imports within the TypeScript compilation, which builtin modules are not part of. Therefore, such imports would erroneously cause the entrypoint to become ignored. This commit fixes the problem by taking the NodeJS builtins into account when dealing with missing imports. Fixes #31522 PR Close #31872
2019-07-27 15:37:04 -04:00
[_('/first/index.js')]: {resolved: [], missing: ['fs']},
}));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: ['fs']},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const entryPoints = getEntryPointsWithDeps(resolver, [first]);
fix(ivy): ngcc - do not consider builtin NodeJS modules as missing (#31872) ngcc analyzes the dependency structure of the entrypoints it needs to process, as the compilation of entrypoints is ordering sensitive: any dependent upon entrypoint must be compiled before its dependees. As part of the analysis of the dependency graph, it is detected when a dependency of entrypoint is not installed, in which case that entrypoint will be marked as ignored. For libraries that work with Angular Universal to run in NodeJS, imports into builtin NodeJS modules can be present. ngcc's dependency analyzer can only resolve imports within the TypeScript compilation, which builtin modules are not part of. Therefore, such imports would erroneously cause the entrypoint to become ignored. This commit fixes the problem by taking the NodeJS builtins into account when dealing with missing imports. Fixes #31522 PR Close #31872
2019-07-27 15:37:04 -04:00
let sorted: SortedEntryPointsInfo;
sorted = resolver.sortEntryPointsByDependency(entryPoints, first);
expect(sorted.entryPoints).toEqual([first]);
expect(sorted.invalidEntryPoints).toEqual([]);
expect(sorted.ignoredDependencies).toEqual([]);
});
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
it('should use the appropriate DependencyHost for each entry-point', () => {
const esm5Host = new EsmDependencyHost(fs, moduleResolver);
const esm2015Host = new EsmDependencyHost(fs, moduleResolver);
fix(ngcc): avoid error due to circular dependency in `EsmDependencyHost` (#34512) Previously, there was circular dependency between `ngcc/src/utils.ts`, `ngcc/src/dependencies/dependency_host.ts` and `ngcc/src/dependencies/esm_dependency_host.ts`. More specifically, `utils.ts` would [import from `esm_dependency_host.ts`][1], which would [import from `dependency_host.ts`][2], which would in turn [import from `utils.ts`][3]. This might be fine in some environments/module formats, but it can cause unclear errors in the transpiled CommonJS/UMD format (given how Node.js handles [cycles in module resolution][4]). (An example error can be found [here][5].) This commit fixes the problem by moving the code that depends on `EsmDependencyHost` out of `utils.ts` and into a dedicated file under `dependencies/`. It also converts the `createDtsDependencyHost()` function to a class for consistency with the rest of the `DependencyHost`s. [1]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/utils.ts#L10 [2]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/esm_dependency_host.ts#L10 [3]: https://github.com/angular/angular/blob/18d89c9c8/packages/compiler-cli/ngcc/src/dependencies/dependency_host.ts#L9 [4]: https://nodejs.org/api/modules.html#modules_cycles [5]: https://circleci.com/gh/angular/angular/577581 PR Close #34512
2020-01-08 12:10:25 -05:00
const dtsHost = new DtsDependencyHost(fs);
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
resolver = new DependencyResolver(
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
fs, new MockLogger(), config, {esm5: esm5Host, esm2015: esm2015Host}, dtsHost);
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(esm5Host, 'collectDependencies')
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
.and.callFake(createFakeComputeDependencies(dependencies));
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
spyOn(esm2015Host, 'collectDependencies')
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
.and.callFake(createFakeComputeDependencies(dependencies));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
spyOn(dtsHost, 'collectDependencies')
.and.callFake(createFakeComputeDependencies(dtsDependencies));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const result = resolver.sortEntryPointsByDependency(
getEntryPointsWithDeps(resolver, [fifth, first, fourth, second, third]));
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
expect(result.entryPoints).toEqual([fifth, fourth, third, second, first]);
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
expect(esm5Host.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(first.path, 'index.js'), jasmine.any(Object));
expect(esm5Host.collectDependencies)
.not.toHaveBeenCalledWith(fs.resolve(second.path, 'sub/index.js'), jasmine.any(Object));
expect(esm5Host.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(third.path, 'index.js'), jasmine.any(Object));
expect(esm5Host.collectDependencies)
.not.toHaveBeenCalledWith(
fs.resolve(fourth.path, 'sub2/index.js'), jasmine.any(Object));
expect(esm5Host.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(fifth.path, 'index.js'), jasmine.any(Object));
expect(esm2015Host.collectDependencies)
.not.toHaveBeenCalledWith(fs.resolve(first.path, 'index.js'), jasmine.any(Object));
expect(esm2015Host.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(second.path, 'sub/index.js'), jasmine.any(Object));
expect(esm2015Host.collectDependencies)
.not.toHaveBeenCalledWith(fs.resolve(third.path, 'index.js'), jasmine.any(Object));
expect(esm2015Host.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(fourth.path, 'sub2/index.js'), jasmine.any(Object));
expect(esm2015Host.collectDependencies)
.not.toHaveBeenCalledWith(fs.resolve(fifth.path, 'index.js'), jasmine.any(Object));
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
expect(dtsHost.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(first.path, 'index.d.ts'), jasmine.any(Object));
expect(dtsHost.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(second.path, 'sub/index.d.ts'), jasmine.any(Object));
expect(dtsHost.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(third.path, 'index.d.ts'), jasmine.any(Object));
expect(dtsHost.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(fourth.path, 'sub2/index.d.ts'), jasmine.any(Object));
expect(dtsHost.collectDependencies)
.toHaveBeenCalledWith(fs.resolve(fifth.path, 'index.d.ts'), jasmine.any(Object));
});
it('should merge "typings-only" dependencies with source dependencies', () => {
spyOn(host, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.js')]: {resolved: [], missing: []},
[_('/second/sub/index.js')]: {resolved: [], missing: [_('/missing1')]},
[_('/third/index.js')]: {resolved: [first.path], missing: []},
}));
spyOn(dtsHost, 'collectDependencies').and.callFake(createFakeComputeDependencies({
[_('/first/index.d.ts')]: {resolved: [], missing: []},
[_('/second/sub/index.d.ts')]: {resolved: [], missing: [_('/missing2')]},
[_('/third/index.d.ts')]: {resolved: [second.path], missing: []},
}));
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
const entryPoints = getEntryPointsWithDeps(resolver, [first, second, third]);
fix(ngcc): capture entry-point dependencies from typings as well as source (#34494) ngcc computes a dependency graph of entry-points to ensure that entry-points are processed in the correct order. Previously only the imports in source files were analysed to determine the dependencies for each entry-point. This is not sufficient when an entry-point has a "type-only" dependency - for example only importing an interface from another entry-point. In this case the "type-only" import does not appear in the source code. It only appears in the typings files. This can cause a dependency to be missed on the entry-point. This commit fixes this by additionally processing the imports in the typings program, as well as the source program. Note that these missing dependencies could cause unexpected flakes when running ngcc in async mode on multiple processes due to the way that ngcc caches files when they are first read from disk. Fixes #34411 // FW-1781 PR Close #34494
2019-12-19 17:43:13 -05:00
const sorted = resolver.sortEntryPointsByDependency(entryPoints);
expect(sorted.entryPoints).toEqual([first]);
expect(sorted.invalidEntryPoints).toEqual([
{entryPoint: second, missingDependencies: [_('/missing1'), _('/missing2')]},
{entryPoint: third, missingDependencies: [_('/second')]},
]);
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
});
function createFakeComputeDependencies(deps: DepMap) {
refactor(ngcc): pass dependency info to `collectDependencies()` (#34494) Rather than return a new object of dependency info from calls to `collectDependencies()` we now pass in an object that will be updated with the dependency info. This is in preparation of a change where we will collect dependency information from more than one `DependencyHost`. Also to better fit with this approach the name is changed from `findDependencies()` to `collectDependencies()`. PR Close #34494
2019-12-19 17:43:12 -05:00
return (entryPointPath: string, {dependencies, missing, deepImports}: DependencyInfo) => {
deps[entryPointPath].resolved.forEach(dep => dependencies.add(absoluteFrom(dep)));
deps[entryPointPath].missing.forEach(
dep => missing.add(fs.isRooted(dep) ? absoluteFrom(dep) : relativeFrom(dep)));
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
if (deps[entryPointPath].deepImports) {
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
deps[entryPointPath].deepImports!.forEach(dep => deepImports.add(dep));
fix(ngcc): allow deep-import warnings to be ignored (#35683) This commit adds a new ngcc configuration, `ignorableDeepImportMatchers` for packages. This is a list of regular expressions matching deep imports that can be safely ignored from that package. Deep imports that are not ignored cause a warning to be logged. // FW-1892 Fixes #35615 PR Close #35683
2020-02-25 10:51:54 -05:00
}
refactor(ivy): implement a virtual file-system layer in ngtsc + ngcc (#30921) To improve cross platform support, all file access (and path manipulation) is now done through a well known interface (`FileSystem`). For testing a number of `MockFileSystem` implementations are provided. These provide an in-memory file-system which emulates operating systems like OS/X, Unix and Windows. The current file system is always available via the static method, `FileSystem.getFileSystem()`. This is also used by a number of static methods on `AbsoluteFsPath` and `PathSegment`, to avoid having to pass `FileSystem` objects around all the time. The result of this is that one must be careful to ensure that the file-system has been initialized before using any of these static methods. To prevent this happening accidentally the current file system always starts out as an instance of `InvalidFileSystem`, which will throw an error if any of its methods are called. You can set the current file-system by calling `FileSystem.setFileSystem()`. During testing you can call the helper function `initMockFileSystem(os)` which takes a string name of the OS to emulate, and will also monkey-patch aspects of the TypeScript library to ensure that TS is also using the current file-system. Finally there is the `NgtscCompilerHost` to be used for any TypeScript compilation, which uses a given file-system. All tests that interact with the file-system should be tested against each of the mock file-systems. A series of helpers have been provided to support such tests: * `runInEachFileSystem()` - wrap your tests in this helper to run all the wrapped tests in each of the mock file-systems. * `addTestFilesToFileSystem()` - use this to add files and their contents to the mock file system for testing. * `loadTestFilesFromDisk()` - use this to load a mirror image of files on disk into the in-memory mock file-system. * `loadFakeCore()` - use this to load a fake version of `@angular/core` into the mock file-system. All ngcc and ngtsc source and tests now use this virtual file-system setup. PR Close #30921
2019-06-06 15:22:32 -04:00
return {dependencies, missing, deepImports};
};
}
perf(ngcc): read dependencies from entry-point manifest (#36486) Previously, even if an entry-point did not need to be processed, ngcc would always parse the files of the entry-point to compute its dependencies. This can take a lot of time for large node_modules. Now these dependencies are cached in the entry-point manifest, and read from there rather than computing them every time. See https://github.com/angular/angular/issues/36414\#issuecomment-608401834 FW-2047 PR Close #36486
2020-04-07 12:47:46 -04:00
function getEntryPointsWithDeps(
resolver: DependencyResolver, entryPoints: EntryPoint[]): EntryPointWithDependencies[] {
return entryPoints.map(entryPoint => resolver.getEntryPointWithDependencies(entryPoint));
}
feat(ivy): ngcc - implement UmdDependencyHost (#25445) The dependency resolution that works out the order in which to process entry-points must also understand UMD formats. PR Close #25445
2019-04-28 15:48:35 -04:00
});
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
});
});