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

475 lines
24 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
* Copyright Google Inc. All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
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';
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
import {DependencyInfo} 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'),
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
package: _('/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'},
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,
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
typings: _('/first/index.d.ts'),
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 = {
path: _('/second'),
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
package: _('/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'},
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,
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
typings: _('/second/sub/index.d.ts'),
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 = {
path: _('/third'),
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
package: _('/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'},
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,
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
typings: _('/third/index.d.ts'),
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 = {
path: _('/fourth'),
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
package: _('/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'},
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,
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
typings: _('/fourth/sub2/index.d.ts'),
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 = {
path: _('/fifth'),
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
package: _('/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'},
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,
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
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
} as EntryPoint;
sixthIgnoreMissing = {
path: _('/sixth'),
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
package: _('/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'},
compiledByAngular: true,
ignoreMissingDependencies: true,
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
typings: _('/sixth/index.d.ts'),
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));
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
const result = resolver.sortEntryPointsByDependency([fifth, first, fourth, second, third]);
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: []},
}));
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
const result = resolver.sortEntryPointsByDependency([first, second]);
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.
const result = resolver.sortEntryPointsByDependency([first, second, third]);
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.
const result = resolver.sortEntryPointsByDependency([second, first, third]);
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.
const result = resolver.sortEntryPointsByDependency([sixthIgnoreMissing, first]);
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: []},
}));
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
const result = resolver.sortEntryPointsByDependency([first, second, sixthIgnoreMissing]);
// 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: []},
}));
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
const result = resolver.sortEntryPointsByDependency([first, second, third]);
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: []},
}));
const result = resolver.sortEntryPointsByDependency([first]);
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({
[_('/project/node_modules/test-package/index.js')]: {
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({
[_('/project/node_modules/test-package/index.d.ts')]: {resolved: [], missing: []},
}));
// 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 = {
name: 'test-package',
path: _('/project/node_modules/test-package'),
package: _('/project/node_modules/test-package'),
packageJson: {esm5: './index.js'},
compiledByAngular: true,
ignoreMissingDependencies: false,
typings: _('/project/node_modules/test-package/index.d.ts'),
} as EntryPoint;
const result = resolver.sortEntryPointsByDependency([testEntryPoint]);
expect(result.entryPoints).toEqual([testEntryPoint]);
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 'test-package' contains deep imports into '${
_('/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', () => {
expect(() => resolver.sortEntryPointsByDependency([
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
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(`There is no appropriate source code format in '/first' entry-point.`);
});
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);
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(() => resolver.sortEntryPointsByDependency([first]))
.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));
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
const result = resolver.sortEntryPointsByDependency([fifth, first, fourth, second, third]);
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): 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
const result = resolver.sortEntryPointsByDependency([fifth, first, fourth, second, third]);
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));
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
const entryPoints = [fifth, first, fourth, second, third];
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')]},
}));
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
const entryPoints = [first];
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']},
}));
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
const entryPoints = [first];
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));
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
const result = resolver.sortEntryPointsByDependency([fifth, first, fourth, second, third]);
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: []},
}));
const entryPoints = [first, second, third];
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};
};
}
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
});
});