angular-cn/packages/core/test/BUILD.bazel

116 lines
3.3 KiB
Python
Raw Normal View History

load("//tools:defaults.bzl", "jasmine_node_test", "karma_web_test_suite", "ts_library")
load("//tools/circular_dependency_test:index.bzl", "circular_dependency_test")
package(default_visibility = ["//visibility:public"])
circular_dependency_test(
name = "circular_deps_test",
entry_point = "angular/packages/core/index.js",
deps = ["//packages/core"],
)
circular_dependency_test(
name = "testing_circular_deps_test",
entry_point = "angular/packages/core/testing/index.js",
deps = ["//packages/core/testing"],
)
fix(core): detect DI parameters in JIT mode for downleveled ES2015 classes (#38463) In the Angular Package Format, we always shipped UMD bundles and previously even ES5 module output. With V10, we removed the ES5 module output but kept the UMD ES5 output. For this, we were able to remove our second TypeScript transpilation. Instead we started only building ES2015 output and then downleveled it to ES5 UMD for the NPM packages. This worked as expected but unveiled an issue in the `@angular/core` reflection capabilities. In JIT mode, Angular determines constructor parameters (for DI) using the `ReflectionCapabilities`. The reflection capabilities basically read runtime metadata of classes to determine the DI parameters. Such metadata can be either stored in static class properties like `ctorParameters` or within TypeScript's `design:params`. If Angular comes across a class that does not have any parameter metadata, it tries to detect if the given class is actually delegating to an inherited class. It does this naively in JIT by checking if the stringified class (function in ES5) matches a certain pattern. e.g. ```js function MatTable() { var _this = _super.apply(this, arguments) || this; ``` These patterns are reluctant to changes of the class output. If a class is not recognized properly, the DI parameters will be assumed empty and the class is **incorrectly** constructed without arguments. This actually happened as part of v10 now. Since we downlevel ES2015 to ES5 (instead of previously compiling sources directly to ES5), the class output changed slightly so that Angular no longer detects it. e.g. ```js var _this = _super.apply(this, __spread(arguments)) || this; ``` This happens because the ES2015 output will receive an auto-generated constructor if the class defines class properties. This constructor is then already containing an explicit `super` call. ```js export class MatTable extends CdkTable { constructor() { super(...arguments); this.disabled = true; } } ``` If we then downlevel this file to ES5 with `--downlevelIteration`, TypeScript adjusts the `super` call so that the spread operator is no longer used (not supported in ES5). The resulting super call is different to the super call that would have been emitted if we would directly transpile to ES5. Ultimately, Angular no longer detects such classes as having an delegate constructor -> and DI breaks. We fix this by expanding the rather naive RegExp patterns used for the reflection capabilities so that downleveled pass-through/delegate constructors are properly detected. There is a risk of a false-positive as we cannot detect whether `__spread` is actually the TypeScript spread helper, but given the reflection patterns already make lots of assumptions (e.g. that `super` is actually the superclass, we should be fine making this assumption too. The false-positive would not result in a broken app, but rather in unnecessary providers being injected (as a noop). Fixes #38453 PR Close #38463
2020-08-14 04:23:53 -04:00
genrule(
name = "downleveled_es5_fixture",
srcs = ["reflection/es2015_inheritance_fixture.ts"],
outs = ["reflection/es5_downleveled_inheritance_fixture.js"],
cmd = """
es2015_out_dir="/tmp/downleveled_es5_fixture/"
es2015_out_file="$$es2015_out_dir/es2015_inheritance_fixture.js"
# Build the ES2015 output and then downlevel it to ES5.
$(execpath @npm//typescript/bin:tsc) $< --outDir $$es2015_out_dir --target ES2015 \
--types --module umd
$(execpath @npm//typescript/bin:tsc) --outFile $@ $$es2015_out_file --allowJs \
--types --target ES5
""",
tools = ["@npm//typescript/bin:tsc"],
)
ts_library(
name = "test_lib",
testonly = True,
srcs = glob(
["**/*.ts"],
exclude = [
"**/*_node_only_spec.ts",
fix(core): detect DI parameters in JIT mode for downleveled ES2015 classes (#38463) In the Angular Package Format, we always shipped UMD bundles and previously even ES5 module output. With V10, we removed the ES5 module output but kept the UMD ES5 output. For this, we were able to remove our second TypeScript transpilation. Instead we started only building ES2015 output and then downleveled it to ES5 UMD for the NPM packages. This worked as expected but unveiled an issue in the `@angular/core` reflection capabilities. In JIT mode, Angular determines constructor parameters (for DI) using the `ReflectionCapabilities`. The reflection capabilities basically read runtime metadata of classes to determine the DI parameters. Such metadata can be either stored in static class properties like `ctorParameters` or within TypeScript's `design:params`. If Angular comes across a class that does not have any parameter metadata, it tries to detect if the given class is actually delegating to an inherited class. It does this naively in JIT by checking if the stringified class (function in ES5) matches a certain pattern. e.g. ```js function MatTable() { var _this = _super.apply(this, arguments) || this; ``` These patterns are reluctant to changes of the class output. If a class is not recognized properly, the DI parameters will be assumed empty and the class is **incorrectly** constructed without arguments. This actually happened as part of v10 now. Since we downlevel ES2015 to ES5 (instead of previously compiling sources directly to ES5), the class output changed slightly so that Angular no longer detects it. e.g. ```js var _this = _super.apply(this, __spread(arguments)) || this; ``` This happens because the ES2015 output will receive an auto-generated constructor if the class defines class properties. This constructor is then already containing an explicit `super` call. ```js export class MatTable extends CdkTable { constructor() { super(...arguments); this.disabled = true; } } ``` If we then downlevel this file to ES5 with `--downlevelIteration`, TypeScript adjusts the `super` call so that the spread operator is no longer used (not supported in ES5). The resulting super call is different to the super call that would have been emitted if we would directly transpile to ES5. Ultimately, Angular no longer detects such classes as having an delegate constructor -> and DI breaks. We fix this by expanding the rather naive RegExp patterns used for the reflection capabilities so that downleveled pass-through/delegate constructors are properly detected. There is a risk of a false-positive as we cannot detect whether `__spread` is actually the TypeScript spread helper, but given the reflection patterns already make lots of assumptions (e.g. that `super` is actually the superclass, we should be fine making this assumption too. The false-positive would not result in a broken app, but rather in unnecessary providers being injected (as a noop). Fixes #38453 PR Close #38463
2020-08-14 04:23:53 -04:00
"reflection/es2015_inheritance_fixture.ts",
],
),
# Visible to //:saucelabs_unit_tests_poc target
visibility = ["//:__pkg__"],
deps = [
"//packages/animations",
"//packages/animations/browser",
"//packages/animations/browser/testing",
"//packages/common",
"//packages/common/locales",
"//packages/compiler",
"//packages/compiler/testing",
"//packages/core",
"//packages/core/src/di/interface",
"//packages/core/src/interface",
"//packages/core/src/reflection",
"//packages/core/src/util",
"//packages/core/testing",
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 07:51:30 -04:00
"//packages/localize/init",
"//packages/platform-browser",
"//packages/platform-browser-dynamic",
"//packages/platform-browser/animations",
"//packages/platform-browser/testing",
"//packages/private/testing",
"//packages/router",
"//packages/router/testing",
"//packages/zone.js/lib:zone_d_ts",
"@npm//rxjs",
],
)
ts_library(
name = "test_node_only_lib",
testonly = True,
srcs = glob(["**/*_node_only_spec.ts"]),
deps = [
":test_lib",
"//packages/compiler",
"//packages/compiler/testing",
"//packages/core",
"//packages/core/src/compiler",
"//packages/core/testing",
"//packages/platform-server",
"//packages/platform-server/testing",
"//packages/private/testing",
],
)
jasmine_node_test(
name = "test",
bootstrap = ["//tools/testing:node_es5"],
fix(core): detect DI parameters in JIT mode for downleveled ES2015 classes (#38463) In the Angular Package Format, we always shipped UMD bundles and previously even ES5 module output. With V10, we removed the ES5 module output but kept the UMD ES5 output. For this, we were able to remove our second TypeScript transpilation. Instead we started only building ES2015 output and then downleveled it to ES5 UMD for the NPM packages. This worked as expected but unveiled an issue in the `@angular/core` reflection capabilities. In JIT mode, Angular determines constructor parameters (for DI) using the `ReflectionCapabilities`. The reflection capabilities basically read runtime metadata of classes to determine the DI parameters. Such metadata can be either stored in static class properties like `ctorParameters` or within TypeScript's `design:params`. If Angular comes across a class that does not have any parameter metadata, it tries to detect if the given class is actually delegating to an inherited class. It does this naively in JIT by checking if the stringified class (function in ES5) matches a certain pattern. e.g. ```js function MatTable() { var _this = _super.apply(this, arguments) || this; ``` These patterns are reluctant to changes of the class output. If a class is not recognized properly, the DI parameters will be assumed empty and the class is **incorrectly** constructed without arguments. This actually happened as part of v10 now. Since we downlevel ES2015 to ES5 (instead of previously compiling sources directly to ES5), the class output changed slightly so that Angular no longer detects it. e.g. ```js var _this = _super.apply(this, __spread(arguments)) || this; ``` This happens because the ES2015 output will receive an auto-generated constructor if the class defines class properties. This constructor is then already containing an explicit `super` call. ```js export class MatTable extends CdkTable { constructor() { super(...arguments); this.disabled = true; } } ``` If we then downlevel this file to ES5 with `--downlevelIteration`, TypeScript adjusts the `super` call so that the spread operator is no longer used (not supported in ES5). The resulting super call is different to the super call that would have been emitted if we would directly transpile to ES5. Ultimately, Angular no longer detects such classes as having an delegate constructor -> and DI breaks. We fix this by expanding the rather naive RegExp patterns used for the reflection capabilities so that downleveled pass-through/delegate constructors are properly detected. There is a risk of a false-positive as we cannot detect whether `__spread` is actually the TypeScript spread helper, but given the reflection patterns already make lots of assumptions (e.g. that `super` is actually the superclass, we should be fine making this assumption too. The false-positive would not result in a broken app, but rather in unnecessary providers being injected (as a noop). Fixes #38453 PR Close #38463
2020-08-14 04:23:53 -04:00
data = [
":downleveled_es5_fixture",
],
shard_count = 4,
deps = [
":test_lib",
":test_node_only_lib",
"//packages/platform-server",
"//packages/platform-server/testing",
"//packages/zone.js/lib:zone_d_ts",
"@npm//base64-js",
"@npm//source-map",
],
)
karma_web_test_suite(
name = "test_web",
fix(core): detect DI parameters in JIT mode for downleveled ES2015 classes (#38463) In the Angular Package Format, we always shipped UMD bundles and previously even ES5 module output. With V10, we removed the ES5 module output but kept the UMD ES5 output. For this, we were able to remove our second TypeScript transpilation. Instead we started only building ES2015 output and then downleveled it to ES5 UMD for the NPM packages. This worked as expected but unveiled an issue in the `@angular/core` reflection capabilities. In JIT mode, Angular determines constructor parameters (for DI) using the `ReflectionCapabilities`. The reflection capabilities basically read runtime metadata of classes to determine the DI parameters. Such metadata can be either stored in static class properties like `ctorParameters` or within TypeScript's `design:params`. If Angular comes across a class that does not have any parameter metadata, it tries to detect if the given class is actually delegating to an inherited class. It does this naively in JIT by checking if the stringified class (function in ES5) matches a certain pattern. e.g. ```js function MatTable() { var _this = _super.apply(this, arguments) || this; ``` These patterns are reluctant to changes of the class output. If a class is not recognized properly, the DI parameters will be assumed empty and the class is **incorrectly** constructed without arguments. This actually happened as part of v10 now. Since we downlevel ES2015 to ES5 (instead of previously compiling sources directly to ES5), the class output changed slightly so that Angular no longer detects it. e.g. ```js var _this = _super.apply(this, __spread(arguments)) || this; ``` This happens because the ES2015 output will receive an auto-generated constructor if the class defines class properties. This constructor is then already containing an explicit `super` call. ```js export class MatTable extends CdkTable { constructor() { super(...arguments); this.disabled = true; } } ``` If we then downlevel this file to ES5 with `--downlevelIteration`, TypeScript adjusts the `super` call so that the spread operator is no longer used (not supported in ES5). The resulting super call is different to the super call that would have been emitted if we would directly transpile to ES5. Ultimately, Angular no longer detects such classes as having an delegate constructor -> and DI breaks. We fix this by expanding the rather naive RegExp patterns used for the reflection capabilities so that downleveled pass-through/delegate constructors are properly detected. There is a risk of a false-positive as we cannot detect whether `__spread` is actually the TypeScript spread helper, but given the reflection patterns already make lots of assumptions (e.g. that `super` is actually the superclass, we should be fine making this assumption too. The false-positive would not result in a broken app, but rather in unnecessary providers being injected (as a noop). Fixes #38453 PR Close #38463
2020-08-14 04:23:53 -04:00
runtime_deps = [":downleveled_es5_fixture"],
deps = [
":test_lib",
],
)