honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/goldens/circular-deps/packages.json

437 lines
14 KiB
JSON
Raw Normal View History

ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/animations/browser/src/render/animation_driver.ts",
"packages/animations/browser/src/render/shared.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/compiler-cli/ngcc/src/packages/configuration.ts",
"packages/compiler-cli/ngcc/src/packages/entry_point.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/compiler-cli/src/metadata/bundle_index_host.ts",
"packages/compiler-cli/src/transformers/metadata_cache.ts",
"packages/compiler-cli/src/metadata/index.ts"
],
[
"packages/compiler-cli/src/metadata/bundle_index_host.ts",
"packages/compiler-cli/src/transformers/metadata_cache.ts",
"packages/compiler-cli/src/transformers/compiler_host.ts",
"packages/compiler-cli/src/metadata/index.ts"
],
[
"packages/compiler-cli/src/metadata/bundle_index_host.ts",
"packages/compiler-cli/src/transformers/metadata_cache.ts",
"packages/compiler-cli/src/transformers/compiler_host.ts",
"packages/compiler-cli/src/transformers/metadata_reader.ts",
"packages/compiler-cli/src/metadata/index.ts"
],
[
"packages/compiler-cli/src/metadata/collector.ts",
"packages/compiler-cli/src/metadata/evaluator.ts"
],
[
"packages/compiler-cli/src/ngtsc/partial_evaluator/src/interface.ts",
"packages/compiler-cli/src/ngtsc/partial_evaluator/src/interpreter.ts"
],
[
"packages/compiler-cli/src/ngtsc/routing/src/analyzer.ts",
"packages/compiler-cli/src/ngtsc/routing/src/lazy.ts"
],
[
"packages/compiler-cli/src/ngtsc/scope/src/component_scope.ts",
"packages/compiler-cli/src/ngtsc/scope/src/local.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/lifecycle_reflector.ts",
"packages/compiler/src/compile_reflector.ts",
"packages/compiler/src/output/output_ast.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/ml_parser/parser.ts",
"packages/compiler/src/ml_parser/ast.ts",
"packages/compiler/src/i18n/i18n_ast.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/ml_parser/parser.ts",
"packages/compiler/src/ml_parser/ast.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/ml_parser/parser.ts",
"packages/compiler/src/ml_parser/lexer.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/ml_parser/parser.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/util.ts",
"packages/compiler/src/constant_pool.ts",
"packages/compiler/src/output/output_ast.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/util.ts",
"packages/compiler/src/output/output_ast.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/compile_metadata.ts",
"packages/compiler/src/util.ts",
"packages/compiler/src/parse_util.ts"
],
[
"packages/compiler/src/output/output_ast.ts",
"packages/compiler/src/render3/view/i18n/meta.ts"
],
[
"packages/compiler/src/output/output_ast.ts",
"packages/compiler/src/render3/view/i18n/meta.ts",
"packages/compiler/src/render3/view/i18n/util.ts"
],
[
"packages/compiler/src/render3/r3_factory.ts",
"packages/compiler/src/render3/view/util.ts",
"packages/compiler/src/render3/view/api.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/compiler/src/render3/view/styling_builder.ts",
"packages/compiler/src/render3/view/template.ts"
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
refactor(core): Remove circular dependency on `render3` JIT and ViewEngine (#39621) JIT needs to identify which type is `ChangeDetectorRef`. It was doing so by importing `ChangeDetectorRef` and than comparing the types. This creates circular dependency as well as prevents tree shaking. The new solution is to brand the class with `__ChangeDetectorRef__` so that it can be identified without creating circular dependency. PR Close #39621
2020-11-10 13:49:53 -05:00
"packages/core/src/change_detection/change_detection.ts",
refactor(core): extract `DoBootstrap` to separate file. (#39621) Extract `DoBootstrap` interface to a separate file to break circular dependency. PR Close #39621
2020-11-10 12:32:26 -05:00
"packages/core/src/change_detection/change_detector_ref.ts",
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
"packages/core/src/render3/view_ref.ts",
refactor(core): Remove circular dependency on `render3` JIT and ViewEngine (#39621) JIT needs to identify which type is `ChangeDetectorRef`. It was doing so by importing `ChangeDetectorRef` and than comparing the types. This creates circular dependency as well as prevents tree shaking. The new solution is to brand the class with `__ChangeDetectorRef__` so that it can be identified without creating circular dependency. PR Close #39621
2020-11-10 13:49:53 -05:00
"packages/core/src/render3/instructions/shared.ts",
"packages/core/src/error_handler.ts",
"packages/core/src/errors.ts",
"packages/core/src/view/types.ts",
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
"packages/core/src/linker/component_factory.ts"
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
],
[
refactor(core): Remove circular dependency between `LContainer` and `ViewRef`. (#39621) `LContainer` stores `ViewRef`s this is not quite right as it creates circular dependency between the two types. Also `LContainer` should not be aware of `ViewRef` which iv ViewEngine specific construct. PR Close #39621
2020-11-10 12:54:05 -05:00
"packages/core/src/change_detection/change_detector_ref.ts",
"packages/core/src/render3/view_ref.ts"
],
[
"packages/core/src/change_detection/change_detector_ref.ts",
refactor(core): Remove circular dependency on `render3` JIT and ViewEngine (#39621) JIT needs to identify which type is `ChangeDetectorRef`. It was doing so by importing `ChangeDetectorRef` and than comparing the types. This creates circular dependency as well as prevents tree shaking. The new solution is to brand the class with `__ChangeDetectorRef__` so that it can be identified without creating circular dependency. PR Close #39621
2020-11-10 13:49:53 -05:00
"packages/core/src/render3/view_ref.ts",
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
"packages/core/src/linker/view_ref.ts"
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
],
[
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
"packages/core/src/change_detection/differs/default_iterable_differ.ts",
"packages/core/src/change_detection/differs/iterable_differs.ts"
],
[
"packages/core/src/change_detection/differs/default_keyvalue_differ.ts",
"packages/core/src/change_detection/differs/keyvalue_differs.ts"
refactor(core): Remove circular dependency between `LContainer` and `ViewRef`. (#39621) `LContainer` stores `ViewRef`s this is not quite right as it creates circular dependency between the two types. Also `LContainer` should not be aware of `ViewRef` which iv ViewEngine specific construct. PR Close #39621
2020-11-10 12:54:05 -05:00
],
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
[
"packages/core/src/di/injectable.ts",
"packages/core/src/di/jit/injectable.ts"
],
[
"packages/core/src/di/injector_compatibility.ts",
"packages/core/src/di/injector.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
refactor(core): Cleanup non-standard `Injector` handling. (#39621) Due to historical reasons `Injector.__NG_ELEMENT_ID__` was set to `-1`. This changes it to be consistent with other `*Ref.__NG_ELEMENT_ID__` constructs. PR Close #39621
2020-11-10 00:09:18 -05:00
[
"packages/core/src/di/injector_token.ts",
"packages/core/src/di/injector.ts"
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/src/di/injector.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/di/null_injector.ts"
refactor(core): use more narrow `QueryList` import to avoid circular deps issue (#36286) Prior to this commit, the `packages/core/src/render3/interfaces/query.ts` file used to import `QueryList` using `../../linker`, which contains a lot of re-exports and as a result, this one import caused a lot of circular deps cycles reported by the tool that checks such deps. In other places in the code the `QueryList` is imported using more narrow import (`linker/query_list`), so this commit uses the same pattern. This change allowed to reduce the number of known cycles from 343 to 207, the golden file was updated accordingly. PR Close #36286
2020-03-27 20:39:14 -04:00
],
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
[
"packages/core/src/di/injector.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/di/r3_injector.ts"
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
],
refactor(core): use more narrow `QueryList` import to avoid circular deps issue (#36286) Prior to this commit, the `packages/core/src/render3/interfaces/query.ts` file used to import `QueryList` using `../../linker`, which contains a lot of re-exports and as a result, this one import caused a lot of circular deps cycles reported by the tool that checks such deps. In other places in the code the `QueryList` is imported using more narrow import (`linker/query_list`), so this commit uses the same pattern. This change allowed to reduce the number of known cycles from 343 to 207, the golden file was updated accordingly. PR Close #36286
2020-03-27 20:39:14 -04:00
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/src/di/reflective_errors.ts",
"packages/core/src/di/reflective_injector.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/src/error_handler.ts",
"packages/core/src/errors.ts",
"packages/core/src/view/types.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
refactor(core): use more narrow `QueryList` import to avoid circular deps issue (#36286) Prior to this commit, the `packages/core/src/render3/interfaces/query.ts` file used to import `QueryList` using `../../linker`, which contains a lot of re-exports and as a result, this one import caused a lot of circular deps cycles reported by the tool that checks such deps. In other places in the code the `QueryList` is imported using more narrow import (`linker/query_list`), so this commit uses the same pattern. This change allowed to reduce the number of known cycles from 343 to 207, the golden file was updated accordingly. PR Close #36286
2020-03-27 20:39:14 -04:00
[
fix(core): memory leak if view container host view is destroyed while view ref is not (#40219) When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes #38648. PR Close #40219
2020-12-21 06:07:50 -05:00
"packages/core/src/error_handler.ts",
"packages/core/src/errors.ts",
"packages/core/src/view/types.ts",
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
"packages/core/src/linker/template_ref.ts",
fix(core): memory leak if view container host view is destroyed while view ref is not (#40219) When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes #38648. PR Close #40219
2020-12-21 06:07:50 -05:00
"packages/core/src/render3/instructions/shared.ts"
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
],
[
fix(core): memory leak if view container host view is destroyed while view ref is not (#40219) When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes #38648. PR Close #40219
2020-12-21 06:07:50 -05:00
"packages/core/src/error_handler.ts",
"packages/core/src/errors.ts",
"packages/core/src/view/types.ts",
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
"packages/core/src/linker/view_container_ref.ts",
fix(core): memory leak if view container host view is destroyed while view ref is not (#40219) When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing that it should stop referencing the container. These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef` is destroyed, we clean it up through the `LContainer` directly. We don't need to worry about the case where the container is destroyed before the view, because containers automatically clean up all of their views upon destruction. Fixes #38648. PR Close #40219
2020-12-21 06:07:50 -05:00
"packages/core/src/render3/instructions/shared.ts"
],
[
"packages/core/src/linker/component_factory_resolver.ts",
"packages/core/src/linker/component_factory.ts",
"packages/core/src/linker/ng_module_factory.ts"
],
[
"packages/core/src/linker/component_factory_resolver.ts",
"packages/core/src/linker/ng_module_factory.ts"
refactor(core): Remove circular dependency on `ApplicationRef` (#39621) `ViewRef` and `ApplicationRef` had a circular reference. This change introduces `ViewRefTracker` which is a subset of `ApplicationRef` for this purpose. PR Close #39621
2020-11-10 15:24:46 -05:00
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
"packages/core/src/metadata/directives.ts",
"packages/core/src/render3/jit/directive.ts"
],
[
"packages/core/src/metadata/directives.ts",
"packages/core/src/render3/jit/directive.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/src/metadata/resource_loading.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
refactor(core): reduce the number of circular deps (#38805) This commit updates several import statements in the core package to decrease the number of cycles detected by the dependency checker tool. PR Close #38805
2020-09-10 15:38:49 -04:00
"packages/core/src/metadata/directives.ts",
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
"packages/core/src/render3/jit/directive.ts",
"packages/core/src/render3/jit/module.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
refactor(core): Cleanup circular dependency between ViewEngine and Ivy `ViewContainerRef`. (#39621) `ViewContainerRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular dependency between ViewEngine `ViewContainerRef` which needs to declare `__NG_ELEMENT_ID__` and ivy factory which needs to create it. The workaround used to be to pass the `ViewContainerRef` through stack but that created a very convoluted code. This refactoring simply bundles the two files together and removes the stack workaround making the code simpler to follow. PR Close #39621
2020-11-09 22:57:47 -05:00
[
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
"packages/core/src/metadata/directives.ts",
"packages/core/src/render3/jit/pipe.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
refactor(core): extract `DoBootstrap` to separate file. (#39621) Extract `DoBootstrap` interface to a separate file to break circular dependency. PR Close #39621
2020-11-10 12:32:26 -05:00
"packages/core/src/metadata/ng_module.ts",
refactor(core): Remove circular dependency on `render3` and `ng_module` (#39621) Extracted `NgModeDef` into a separate file to break the circular dependency. PR Close #39621
2020-11-10 13:23:38 -05:00
"packages/core/src/render3/jit/module.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
refactor(core): Cleanup circular dependency between ViewEngine and Ivy `ChangeDetectorRef`. (#39621) `ChangeDetectorRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular dependency between ViewEngine `ChangeDetectorRef` which needs to declare `__NG_ELEMENT_ID__` and ivy factory which needs to create it. The workaround used to be to pass the `ChangeDetectorRef` through stack but that created a very convoluted code. This refactoring simply bundles the two files together and removes the stack workaround making the code simpler to follow. PR Close #39621
2020-11-09 23:05:23 -05:00
"packages/core/src/render3/interfaces/container.ts",
refactor(core): clean up circular dependencies (#39233) Moved code from `interfaces/i18n.ts` which was causing circular dependencies PR Close #39233
2020-10-17 15:20:12 -04:00
"packages/core/src/render3/interfaces/node.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/render3/interfaces/view.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
refactor(core): Cleanup circular dependency between ViewEngine and Ivy `ChangeDetectorRef`. (#39621) `ChangeDetectorRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular dependency between ViewEngine `ChangeDetectorRef` which needs to declare `__NG_ELEMENT_ID__` and ivy factory which needs to create it. The workaround used to be to pass the `ChangeDetectorRef` through stack but that created a very convoluted code. This refactoring simply bundles the two files together and removes the stack workaround making the code simpler to follow. PR Close #39621
2020-11-09 23:05:23 -05:00
"packages/core/src/render3/interfaces/container.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/render3/interfaces/view.ts"
refactor(core): Cleanup circular dependency between ViewEngine and Ivy `ChangeDetectorRef`. (#39621) `ChangeDetectorRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular dependency between ViewEngine `ChangeDetectorRef` which needs to declare `__NG_ELEMENT_ID__` and ivy factory which needs to create it. The workaround used to be to pass the `ChangeDetectorRef` through stack but that created a very convoluted code. This refactoring simply bundles the two files together and removes the stack workaround making the code simpler to follow. PR Close #39621
2020-11-09 23:05:23 -05:00
],
refactor(core): Remove circular dependency between `LContainer` and `ViewRef`. (#39621) `LContainer` stores `ViewRef`s this is not quite right as it creates circular dependency between the two types. Also `LContainer` should not be aware of `ViewRef` which iv ViewEngine specific construct. PR Close #39621
2020-11-10 12:54:05 -05:00
[
"packages/core/src/render3/interfaces/definition.ts",
"packages/core/src/render3/interfaces/node.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/render3/interfaces/view.ts"
refactor(core): Remove circular dependency between `LContainer` and `ViewRef`. (#39621) `LContainer` stores `ViewRef`s this is not quite right as it creates circular dependency between the two types. Also `LContainer` should not be aware of `ViewRef` which iv ViewEngine specific construct. PR Close #39621
2020-11-10 12:54:05 -05:00
],
[
"packages/core/src/render3/interfaces/node.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/render3/interfaces/view.ts"
refactor(core): Remove circular dependency between `LContainer` and `ViewRef`. (#39621) `LContainer` stores `ViewRef`s this is not quite right as it creates circular dependency between the two types. Also `LContainer` should not be aware of `ViewRef` which iv ViewEngine specific construct. PR Close #39621
2020-11-10 12:54:05 -05:00
],
[
"packages/core/src/render3/interfaces/node.ts",
"packages/core/src/render3/interfaces/view.ts",
refactor(core): clean up circular dependencies (#39722) Clean up circular dependencies in core by pulling symbols out to their respective files. PR Close #39722
2020-11-16 22:35:28 -05:00
"packages/core/src/render3/interfaces/query.ts"
refactor(core): Cleanup circular dependency between ViewEngine and Ivy `ChangeDetectorRef`. (#39621) `ChangeDetectorRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular dependency between ViewEngine `ChangeDetectorRef` which needs to declare `__NG_ELEMENT_ID__` and ivy factory which needs to create it. The workaround used to be to pass the `ChangeDetectorRef` through stack but that created a very convoluted code. This refactoring simply bundles the two files together and removes the stack workaround making the code simpler to follow. PR Close #39621
2020-11-09 23:05:23 -05:00
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/src/render3/interfaces/query.ts",
"packages/core/src/render3/interfaces/view.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: fix circular deps failure (#36629) With the large scale refactoring of the repo to the new version of clang-format, some import orders were changed. Specifically the imports found in this range. The file previously read: import {TestBed} from './test_bed'; import {ComponentFixtureAutoDetect, ComponentFixtureNoNgZone, TestBedStatic, TestComponentRenderer, TestModuleMetadata} from './test_bed_common'; import {R3TestBedCompiler} from './r3_test_bed_compiler'; and now reads: import {R3TestBedCompiler} from './r3_test_bed_compiler'; import {TestBed} from './test_bed'; import {ComponentFixtureAutoDetect, ComponentFixtureNoNgZone, TestBedStatic, TestComponentRenderer, TestModuleMetadata} from './test_bed_common'; This change in order cause the circular dependency to be entered earlier and changed the golden file for our circular deps discovery. PR Close #36629
2020-04-14 16:17:43 -04:00
"packages/core/testing/src/r3_test_bed_compiler.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/testing/src/test_bed_common.ts",
build: fix circular deps failure (#36629) With the large scale refactoring of the repo to the new version of clang-format, some import orders were changed. Specifically the imports found in this range. The file previously read: import {TestBed} from './test_bed'; import {ComponentFixtureAutoDetect, ComponentFixtureNoNgZone, TestBedStatic, TestComponentRenderer, TestModuleMetadata} from './test_bed_common'; import {R3TestBedCompiler} from './r3_test_bed_compiler'; and now reads: import {R3TestBedCompiler} from './r3_test_bed_compiler'; import {TestBed} from './test_bed'; import {ComponentFixtureAutoDetect, ComponentFixtureNoNgZone, TestBedStatic, TestComponentRenderer, TestModuleMetadata} from './test_bed_common'; This change in order cause the circular dependency to be entered earlier and changed the golden file for our circular deps discovery. PR Close #36629
2020-04-14 16:17:43 -04:00
"packages/core/testing/src/test_bed.ts",
"packages/core/testing/src/r3_test_bed.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/core/testing/src/r3_test_bed.ts",
"packages/core/testing/src/test_bed.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/abstract_control_directive.ts",
"packages/forms/src/model.ts",
refactor(forms): move common validators-related logic to the `AbstractControlDirective` class (#38280) This commit refactors validators-related logic that is common across most of the directives. A couple notes on this refactoring: * common logic was moved to the `AbstractControlDirective` class (including `validator` and `asyncValidator` getters) * sync/async validators are now composed in `AbstractControlDirective` class eagerly when validators are set with `_setValidators` and `_setAsyncValidators` calls and the result is stored in directive instance (thus getters return cached versions of validator fn). This is needed to make sure composed validator function remains the same (retains its identity) for a given directive instance, so that this function can be added and later removed from an instance of an AbstractControl-based class (like `FormControl`). Preserving validator function is required to perform proper cleanup (in followup PRs) of the AbstractControl-based classes when a directive is destroyed. PR Close #38280
2020-07-27 22:31:40 -04:00
"packages/forms/src/directives/shared.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/abstract_control_directive.ts",
"packages/forms/src/model.ts",
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
"packages/forms/src/directives/shared.ts",
"packages/forms/src/directives/abstract_form_group_directive.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/control_container.ts"
refactor(forms): move common validators-related logic to the `AbstractControlDirective` class (#38280) This commit refactors validators-related logic that is common across most of the directives. A couple notes on this refactoring: * common logic was moved to the `AbstractControlDirective` class (including `validator` and `asyncValidator` getters) * sync/async validators are now composed in `AbstractControlDirective` class eagerly when validators are set with `_setValidators` and `_setAsyncValidators` calls and the result is stored in directive instance (thus getters return cached versions of validator fn). This is needed to make sure composed validator function remains the same (retains its identity) for a given directive instance, so that this function can be added and later removed from an instance of an AbstractControl-based class (like `FormControl`). Preserving validator function is required to perform proper cleanup (in followup PRs) of the AbstractControl-based classes when a directive is destroyed. PR Close #38280
2020-07-27 22:31:40 -04:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/abstract_control_directive.ts",
"packages/forms/src/model.ts",
refactor(forms): move common validators-related logic to the `AbstractControlDirective` class (#38280) This commit refactors validators-related logic that is common across most of the directives. A couple notes on this refactoring: * common logic was moved to the `AbstractControlDirective` class (including `validator` and `asyncValidator` getters) * sync/async validators are now composed in `AbstractControlDirective` class eagerly when validators are set with `_setValidators` and `_setAsyncValidators` calls and the result is stored in directive instance (thus getters return cached versions of validator fn). This is needed to make sure composed validator function remains the same (retains its identity) for a given directive instance, so that this function can be added and later removed from an instance of an AbstractControl-based class (like `FormControl`). Preserving validator function is required to perform proper cleanup (in followup PRs) of the AbstractControl-based classes when a directive is destroyed. PR Close #38280
2020-07-27 22:31:40 -04:00
"packages/forms/src/directives/shared.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/abstract_form_group_directive.ts",
"packages/forms/src/directives/control_container.ts",
"packages/forms/src/directives/form_interface.ts",
"packages/forms/src/directives/ng_control.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
"packages/forms/src/directives/abstract_form_group_directive.ts",
"packages/forms/src/directives/control_container.ts",
"packages/forms/src/directives/form_interface.ts"
],
[
"packages/forms/src/directives/abstract_form_group_directive.ts",
"packages/forms/src/directives/control_container.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/form_interface.ts",
"packages/forms/src/model.ts",
"packages/forms/src/directives/shared.ts"
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
],
[
"packages/forms/src/directives/abstract_form_group_directive.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/shared.ts"
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
],
[
"packages/forms/src/directives/abstract_form_group_directive.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/model.ts",
"packages/forms/src/directives/shared.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
"packages/forms/src/directives/control_container.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/form_interface.ts",
"packages/forms/src/directives/ng_control.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/ng_form.ts",
"packages/forms/src/directives/ng_model.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/ng_form.ts",
"packages/forms/src/directives/ng_model.ts",
"packages/forms/src/directives/ng_model_group.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_control_directive.ts",
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
"packages/forms/src/directives/shared.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
"packages/forms/src/directives/reactive_directives/form_group_directive.ts",
"packages/forms/src/directives/reactive_directives/form_control_name.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
[
"packages/forms/src/directives/reactive_directives/form_control_directive.ts",
"packages/forms/src/model.ts",
"packages/forms/src/directives/shared.ts",
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
"packages/forms/src/directives/reactive_directives/form_group_directive.ts",
"packages/forms/src/directives/reactive_directives/form_control_name.ts"
],
[
"packages/forms/src/directives/reactive_directives/form_control_name.ts",
"packages/forms/src/directives/reactive_directives/form_group_directive.ts"
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_control_name.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_group_directive.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_control_name.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/shared.ts",
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_group_directive.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_control_name.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/model.ts",
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
"packages/forms/src/directives/shared.ts",
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_group_directive.ts"
],
[
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
"packages/forms/src/directives/reactive_directives/form_group_directive.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/reactive_directives/form_group_name.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
"packages/forms/src/directives/reactive_directives/form_group_directive.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/shared.ts",
"packages/forms/src/directives/reactive_directives/form_group_name.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
[
"packages/forms/src/directives/reactive_directives/form_group_directive.ts",
"packages/forms/src/model.ts",
"packages/forms/src/directives/shared.ts",
"packages/forms/src/directives/reactive_directives/form_group_name.ts"
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/shared.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/reactive_directives/form_group_name.ts",
"packages/forms/src/model.ts",
"packages/forms/src/directives/shared.ts"
],
[
"packages/forms/src/directives/shared.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/model.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/shared.ts",
"packages/forms/src/validators.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/directives/validators.ts",
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/model.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
[
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
"packages/forms/src/directives/shared.ts",
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/forms/src/validators.ts",
"packages/forms/src/model.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
],
fix(forms): more precise control cleanup (#39623) Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers, etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes all callbacks related to the onChange and disabled state handling. This is causing problems when a form control is bound to multiple FormControlName` directives, causing other instances of that directive to stop working correctly when the first one is destroyed. This commit updates the cleanup logic to only remove callbacks added while setting up a control for a given directive instance. The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed (missing this function calls in some other places causes memory leak issues). PR Close #39623
2020-11-10 01:58:19 -05:00
[
"packages/forms/src/directives/validators.ts",
"packages/forms/src/validators.ts"
],
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
[
"packages/language-service/src/completions.ts",
"packages/language-service/src/template.ts",
"packages/language-service/src/typescript_host.ts",
"packages/language-service/src/language_service.ts"
],
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
[
"packages/language-service/src/template.ts",
"packages/language-service/src/typescript_host.ts"
],
[
build: ts-circular-deps tool should normalize golden (#36505) Currently the golden output of the circular-deps tool is purely based on the order of source files passed to the tool, and on the amount of imports inside source files. This is actually resulting in deterministic output as running the tool multiple times without any changes to source files, results in the same output. Though it seems like the tool is too strict and we can avoid unnecessary golden changes if: 1. A source file that is part of a cycle is imported earlier (in terms of how the analyzer visits them). This could result in the cycle path starting with a different source file. 2. Source files which are not part of a cycle are imported earlier (in terms of how the analyzer visits them). This could result in moved items in the golden if re-approved (even though the cycles remain the same) To fix this, we normalize the cycle path array that serves as serializable data structure for the text-based goldens. Since the paths represents a cycle, the path can be shifted in a deterministic way so that cycles don't change unnecessarily in the golden, and to simplify comparison of cycles. Additionally, we sort the cycles in a deterministic way so that the golden doesn't change unnecessarily (as explained above). PR Close #36505
2020-04-08 08:50:10 -04:00
"packages/router/src/config.ts",
"packages/router/src/router_state.ts"
],
[
"packages/router/src/config.ts",
"packages/router/src/router_state.ts",
"packages/router/src/shared.ts"
],
[
"packages/router/src/directives/router_outlet.ts",
"packages/router/src/router_outlet_context.ts"
],
[
"packages/router/src/operators/activate_routes.ts",
"packages/router/src/router.ts"
],
[
"packages/router/src/operators/apply_redirects.ts",
"packages/router/src/router.ts"
],
[
"packages/router/src/operators/check_guards.ts",
"packages/router/src/router.ts"
],
[
"packages/router/src/operators/recognize.ts",
"packages/router/src/router.ts"
],
[
"packages/router/src/operators/resolve_data.ts",
"packages/router/src/router.ts"
],
[
"packages/router/src/shared.ts",
"packages/router/src/url_tree.ts"
],
[
"packages/router/src/shared.ts",
"packages/router/src/url_tree.ts",
"packages/router/src/utils/collection.ts"
ci: set up golden file for typescript circular dependencies (#35647) Sets up a golden file for the TypeScript circular dependencies for source files inside of the `packages/` folder. Also sets up the appropriate Yarn shorthand scripts, and a codeowner group that is soley responsible for verifying changes to the golden. PR Close #35647
2020-02-24 06:08:24 -05:00
]
]