honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/compiler-cli/ngcc/BUILD.bazel

41 lines
1.4 KiB
Python
Raw Normal View History

style: enforce buildifier lint on CI (#28186) PR Close #28186
2019-01-16 04:19:01 -05:00
load("//tools:defaults.bzl", "ts_library")
feat(ivy): ngcc project skeleton (#24897) PR Close #24897
2018-07-16 03:49:56 -04:00
style: enforce buildifier lint on CI (#28186) PR Close #28186
2019-01-16 04:19:01 -05:00
package(default_visibility = ["//visibility:public"])
feat(ivy): ngcc project skeleton (#24897) PR Close #24897
2018-07-16 03:49:56 -04:00
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",
feat(ivy): ngcc project skeleton (#24897) PR Close #24897
2018-07-16 03:49:56 -04:00
deps = [
"//packages:types",
"//packages/compiler",
"//packages/compiler-cli/src/ngtsc/annotations",
feat(ivy): detect cycles and use remote scoping of components if needed (#28169) By its nature, Ivy alters the import graph of a TS program, adding imports where template dependencies exist. For example, if ComponentA uses PipeB in its template, Ivy will insert an import of PipeB into the file in which ComponentA is declared. Any insertion of an import into a program has the potential to introduce a cycle into the import graph. If for some reason the file in which PipeB is declared imports the file in which ComponentA is declared (maybe it makes use of a service or utility function that happens to be in the same file as ComponentA) then this could create an import cycle. This turns out to happen quite regularly in larger Angular codebases. TypeScript and the Ivy runtime have no issues with such cycles. However, other tools are not so accepting. In particular the Closure Compiler is very anti-cycle. To mitigate this problem, it's necessary to detect when the insertion of an import would create a cycle. ngtsc can then use a different strategy, known as "remote scoping", instead of directly writing a reference from one component to another. Under remote scoping, a function 'setComponentScope' is called after the declaration of the component's module, which does not require the addition of new imports. FW-647 #resolve PR Close #28169
2019-01-15 15:32:10 -05:00
"//packages/compiler-cli/src/ngtsc/cycles",
feat(ivy): ngcc - support ngcc "migrations" (#31544) This commit implements support for the ngcc migrations as designed in https://hackmd.io/KhyrFV1VQHmeQsgfJq6AyQ PR Close #31544
2019-07-18 16:05:32 -04:00
"//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",
refactor(ivy): split apart the 'metadata' package in the ngtsc compiler (#27743) This refactoring moves code around between a few of the ngtsc subpackages, with the goal of having a more logical package structure. Additional interfaces are also introduced where they make sense. The 'metadata' package formerly contained both the partial evaluator, the TypeScriptReflectionHost as well as some other reflection functions, and the Reference interface and various implementations. This package was split into 3 parts. The partial evaluator now has its own package 'partial_evaluator', and exists behind an interface PartialEvaluator instead of a top-level function. In the future this will be useful for reducing churn as the partial evaluator becomes more complicated. The TypeScriptReflectionHost and other miscellaneous functions have moved into a new 'reflection' package. The former 'host' package which contained the ReflectionHost interface and associated types was also merged into this new 'reflection' package. Finally, the Reference APIs were moved to the 'imports' package, which will consolidate all import-related logic in ngtsc. PR Close #27743
2018-12-18 12:48:15 -05:00
"//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",
refactor(ivy): move metadata registration to its own package (#29698) Previously, metadata registration (the recording of collected metadata during analysis of directives, pipes, and NgModules) was only used to produce the `LocalModuleScope`, and thus was handled by the `LocalModuleScopeRegistry`. However, the template type-checker also needs information about registered directives, outside of the NgModule scope determinations. Rather than reuse the scope registry for an unintended purpose, this commit introduces new abstractions for metadata registration and lookups in a separate 'metadata' package, which the scope registry implements. This paves the way for a future commit to make use of this metadata for the template type-checking system. Testing strategy: this commit is a refactoring which introduces no new functionality, so existing tests are sufficient. PR Close #29698
2019-03-26 17:02:16 -04:00
"//packages/compiler-cli/src/ngtsc/metadata",
refactor(ivy): split apart the 'metadata' package in the ngtsc compiler (#27743) This refactoring moves code around between a few of the ngtsc subpackages, with the goal of having a more logical package structure. Additional interfaces are also introduced where they make sense. The 'metadata' package formerly contained both the partial evaluator, the TypeScriptReflectionHost as well as some other reflection functions, and the Reference interface and various implementations. This package was split into 3 parts. The partial evaluator now has its own package 'partial_evaluator', and exists behind an interface PartialEvaluator instead of a top-level function. In the future this will be useful for reducing churn as the partial evaluator becomes more complicated. The TypeScriptReflectionHost and other miscellaneous functions have moved into a new 'reflection' package. The former 'host' package which contained the ReflectionHost interface and associated types was also merged into this new 'reflection' package. Finally, the Reference APIs were moved to the 'imports' package, which will consolidate all import-related logic in ngtsc. PR Close #27743
2018-12-18 12:48:15 -05:00
"//packages/compiler-cli/src/ngtsc/partial_evaluator",
feat(ivy): performance trace mechanism for ngtsc (#29380) This commit adds a `tracePerformance` option for tsconfig.json. When specified, it causes a JSON file with timing information from the ngtsc compiler to be emitted at the specified path. This tracing system is used to instrument the analysis/emit phases of compilation, and will be useful in debugging future integration work with @angular/cli. See ngtsc/perf/README.md for more details. PR Close #29380
2019-03-18 14:16:38 -04:00
"//packages/compiler-cli/src/ngtsc/perf",
refactor(ivy): split apart the 'metadata' package in the ngtsc compiler (#27743) This refactoring moves code around between a few of the ngtsc subpackages, with the goal of having a more logical package structure. Additional interfaces are also introduced where they make sense. The 'metadata' package formerly contained both the partial evaluator, the TypeScriptReflectionHost as well as some other reflection functions, and the Reference interface and various implementations. This package was split into 3 parts. The partial evaluator now has its own package 'partial_evaluator', and exists behind an interface PartialEvaluator instead of a top-level function. In the future this will be useful for reducing churn as the partial evaluator becomes more complicated. The TypeScriptReflectionHost and other miscellaneous functions have moved into a new 'reflection' package. The former 'host' package which contained the ReflectionHost interface and associated types was also merged into this new 'reflection' package. Finally, the Reference APIs were moved to the 'imports' package, which will consolidate all import-related logic in ngtsc. PR Close #27743
2018-12-18 12:48:15 -05:00
"//packages/compiler-cli/src/ngtsc/reflection",
refactor(ivy): extract selector scope logic to a new ngtsc package (#28852) This commit splits apart selector_scope.ts in ngtsc and extracts the logic into two separate classes, the LocalModuleScopeRegistry and the DtsModuleScopeResolver. The logic is cleaned up significantly and new tests are added to verify behavior. LocalModuleScopeRegistry implements the NgModule semantics for compilation scopes, and handles NgModules declared in the current compilation unit. DtsModuleScopeResolver implements simpler logic for export scopes and handles NgModules declared in .d.ts files. This is done in preparation for the addition of re-export logic to solve StrictDeps issues. PR Close #28852
2019-02-19 15:05:03 -05:00
"//packages/compiler-cli/src/ngtsc/scope",
feat(ivy): ngcc project skeleton (#24897) PR Close #24897
2018-07-16 03:49:56 -04:00
"//packages/compiler-cli/src/ngtsc/transform",
refactor(ivy): move the expr/stmt translator to a separate target (#26203) Template type-checking will make use of expression and statement translation as well as the ImportManager, so this code needs to live in a separate build target which can be depended on by both the main ngtsc transform as well as the template type-checking mechanism. This refactor introduces a separate build target for that code. PR Close #26203
2018-09-21 15:15:06 -04:00
"//packages/compiler-cli/src/ngtsc/translator",
fix(ivy): render alias exports for private declarations if possible (#28735) Sometimes declarations are not exported publicly but are exported under a private name. In this case, rather than adding a completely new export to the entry point, we should create an export that aliases the private name back to the original public name. This is important when the typings files have been rolled-up using a tool such as the [API Extractor](https://api-extractor.com/). In this case the internal type of an aliased private export will be removed completely from the typings file, so there is no "original" type to re-export. For example: If there are the following TS files: **entry-point.ts** ```ts export {Internal as External} from './internal'; ``` **internal.ts** ```ts export class Internal { foo(): void; } ``` Then the API Extractor might roll up the .d.ts files into: ```ts export declare class External { foo(): void; } ``` In this case ngcc should add an export so the file looks like: ```ts export declare class External { foo(): void; } export {External as Internal}; ``` PR Close #28735
2019-02-14 12:59:46 -05:00
"//packages/compiler-cli/src/ngtsc/util",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 12:54:42 -05:00
"@npm//@types/convert-source-map",
"@npm//@types/node",
feat(ngcc): support version ranges in project/default configurations (#33008) By appending a version range to the package name, it is now possible to target configuration to specific versions of a package. PR Close #33008
2019-10-04 06:54:33 -04:00
"@npm//@types/semver",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 12:54:42 -05:00
"@npm//@types/yargs",
"@npm//canonical-path",
"@npm//dependency-graph",
"@npm//magic-string",
feat(ngcc): support version ranges in project/default configurations (#33008) By appending a version range to the package name, it is now possible to target configuration to specific versions of a package. PR Close #33008
2019-10-04 06:54:33 -04:00
"@npm//semver",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 12:54:42 -05:00
"@npm//source-map",
"@npm//typescript",
feat(ivy): ngcc project skeleton (#24897) PR Close #24897
2018-07-16 03:49:56 -04:00
],
)