angular-cn/packages/compiler-cli/ngcc/BUILD.bazel

41 lines
1.4 KiB
Python
Raw Normal View History

load("//tools:defaults.bzl", "ts_library")
package(default_visibility = ["//visibility:public"])
ts_library(
name = "ngcc",
srcs = glob([
"*.ts",
"**/*.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
tsconfig = "//packages/compiler-cli:tsconfig",
deps = [
"//packages:types",
"//packages/compiler",
"//packages/compiler-cli/src/ngtsc/annotations",
"//packages/compiler-cli/src/ngtsc/cycles",
"//packages/compiler-cli/src/ngtsc/diagnostics",
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
"//packages/compiler-cli/src/ngtsc/file_system",
"//packages/compiler-cli/src/ngtsc/imports",
perf(ivy): reuse prior analysis work during incremental builds (#34288) Previously, the compiler performed an incremental build by analyzing and resolving all classes in the program (even unchanged ones) and then using the dependency graph information to determine which .js files were stale and needed to be re-emitted. This algorithm produced "correct" rebuilds, but the cost of re-analyzing the entire program turned out to be higher than anticipated, especially for component-heavy compilations. To achieve performant rebuilds, it is necessary to reuse previous analysis results if possible. Doing this safely requires knowing when prior work is viable and when it is stale and needs to be re-done. The new algorithm implemented by this commit is such: 1) Each incremental build starts with knowledge of the last known good dependency graph and analysis results from the last successful build, plus of course information about the set of files changed. 2) The previous dependency graph's information is used to determine the set of source files which have "logically" changed. A source file is considered logically changed if it or any of its dependencies have physically changed (on disk) since the last successful compilation. Any logically unchanged dependencies have their dependency information copied over to the new dependency graph. 3) During the `TraitCompiler`'s loop to consider all source files in the program, if a source file is logically unchanged then its previous analyses are "adopted" (and their 'register' steps are run). If the file is logically changed, then it is re-analyzed as usual. 4) Then, incremental build proceeds as before, with the new dependency graph being used to determine the set of files which require re-emitting. This analysis reuse avoids template parsing operations in many circumstances and significantly reduces the time it takes ngtsc to rebuild a large application. Future work will increase performance even more, by tackling a variety of other opportunities to reuse or avoid work. PR Close #34288
2019-12-05 19:03:17 -05:00
"//packages/compiler-cli/src/ngtsc/incremental:api",
"//packages/compiler-cli/src/ngtsc/metadata",
"//packages/compiler-cli/src/ngtsc/partial_evaluator",
"//packages/compiler-cli/src/ngtsc/perf",
"//packages/compiler-cli/src/ngtsc/reflection",
"//packages/compiler-cli/src/ngtsc/scope",
"//packages/compiler-cli/src/ngtsc/transform",
"//packages/compiler-cli/src/ngtsc/translator",
"//packages/compiler-cli/src/ngtsc/util",
"@npm//@types/convert-source-map",
"@npm//@types/node",
"@npm//@types/semver",
"@npm//@types/yargs",
"@npm//canonical-path",
"@npm//dependency-graph",
"@npm//magic-string",
"@npm//semver",
"@npm//source-map",
"@npm//typescript",
],
)