angular-cn/packages/compiler-cli/src/ngtsc/file_system/index.ts

/**
 * @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
 */
export {CachedFileSystem} from './src/cached_file_system';
export {NgtscCompilerHost} from './src/compiler_host';
export {absoluteFrom, absoluteFromSourceFile, basename, dirname, getFileSystem, isRoot, join, relative, relativeFrom, resolve, setFileSystem} from './src/helpers';
export {LogicalFileSystem, LogicalProjectPath} from './src/logical';
export {NodeJSFileSystem} from './src/node_js_file_system';
export {AbsoluteFsPath, FileStats, FileSystem, PathSegment, PathString} from './src/types';
export {getSourceFileOrError} from './src/util';
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 20:22:32 +01: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(ivy): ngcc - add a cache to the FileSystem (#30525) When profiling ngcc it is notable that a large amount of time is spent dealing with an exception that is thrown (and handled internally by fs) when checking the existence of a file. We check file existence a lot in both finding entry-points and when TS is compiling code. This commit adds a simple cached `FileSystem`, which wraps a real `FileSystem` delegate. This will reduce the number of calls through to `fs.exists()` and `fs.readFile()` on the delegate. Initial benchmarks indicate that the cache is miss to hit ratio for `exists()` is about 2:1, which means that we save about 1/3 of the calls to `fs.existsSync()`. Note that this implements a "non-expiring" cache, so it is not suitable for a long lived `FileSystem`, where files may be modified externally. The cache will be updated if a file is changed or moved via calls to `FileSystem` methods but it will not be aware of changes to the files system from outside the `FileSystem` service. For ngcc we must create a new `FileSystem` service for each run of `mainNgcc` and ensure that all file operations (including TS compilation) use the `FileSystem` service. This ensures that it is very unlikely that a file will change externally during `mainNgcc` processing. PR Close #30525 2019-05-15 13:38:19 +01:00			`export {CachedFileSystem} from './src/cached_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 20:22:32 +01:00			`export {NgtscCompilerHost} from './src/compiler_host';`
			`export {absoluteFrom, absoluteFromSourceFile, basename, dirname, getFileSystem, isRoot, join, relative, relativeFrom, resolve, setFileSystem} from './src/helpers';`
			`export {LogicalFileSystem, LogicalProjectPath} from './src/logical';`
			`export {NodeJSFileSystem} from './src/node_js_file_system';`
			`export {AbsoluteFsPath, FileStats, FileSystem, PathSegment, PathString} from './src/types';`
			`export {getSourceFileOrError} from './src/util';`