2019-11-13 12:08:38 -05:00
|
|
|
load("//tools:defaults.bzl", "jasmine_node_test", "karma_web_test_suite", "ts_library")
|
2020-01-14 09:31:13 -05:00
|
|
|
load("//tools/circular_dependency_test:index.bzl", "circular_dependency_test")
|
2017-12-06 09:56:49 -05:00
|
|
|
|
2019-01-16 04:19:01 -05:00
|
|
|
package(default_visibility = ["//visibility:public"])
|
|
|
|
|
|
2020-01-14 09:31:13 -05:00
|
|
|
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 \
|
2021-03-21 14:10:36 -04:00
|
|
|
--types --target ES5 --downlevelIteration
|
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
|
|
|
""",
|
|
|
|
|
tools = ["@npm//typescript/bin:tsc"],
|
|
|
|
|
)
|
|
|
|
|
|
2017-12-06 09:56:49 -05:00
|
|
|
ts_library(
|
|
|
|
|
name = "test_lib",
|
2018-10-16 02:24:22 -04:00
|
|
|
testonly = True,
|
2017-12-01 17:23:03 -05:00
|
|
|
srcs = glob(
|
|
|
|
|
["**/*.ts"],
|
2017-12-16 14:35:47 -05:00
|
|
|
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",
|
2017-12-16 14:35:47 -05:00
|
|
|
],
|
2017-12-01 17:23:03 -05:00
|
|
|
),
|
2019-12-06 10:17:09 -05:00
|
|
|
# Visible to //:saucelabs_unit_tests_poc target
|
2018-12-18 01:09:39 -05:00
|
|
|
visibility = ["//:__pkg__"],
|
2017-12-06 09:56:49 -05:00
|
|
|
deps = [
|
|
|
|
|
"//packages/animations",
|
|
|
|
|
"//packages/animations/browser",
|
|
|
|
|
"//packages/animations/browser/testing",
|
|
|
|
|
"//packages/common",
|
2019-05-17 10:13:31 -04:00
|
|
|
"//packages/common/locales",
|
2017-12-06 09:56:49 -05:00
|
|
|
"//packages/compiler",
|
|
|
|
|
"//packages/compiler/testing",
|
|
|
|
|
"//packages/core",
|
2019-01-09 16:49:16 -05:00
|
|
|
"//packages/core/src/di/interface",
|
|
|
|
|
"//packages/core/src/interface",
|
2019-01-11 19:07:01 -05:00
|
|
|
"//packages/core/src/reflection",
|
2019-01-09 16:49:16 -05:00
|
|
|
"//packages/core/src/util",
|
2017-12-06 09:56:49 -05:00
|
|
|
"//packages/core/testing",
|
2019-08-10 07:51:30 -04:00
|
|
|
"//packages/localize/init",
|
2017-12-06 09:56:49 -05:00
|
|
|
"//packages/platform-browser",
|
|
|
|
|
"//packages/platform-browser-dynamic",
|
|
|
|
|
"//packages/platform-browser/animations",
|
|
|
|
|
"//packages/platform-browser/testing",
|
2018-07-27 16:49:22 -04:00
|
|
|
"//packages/private/testing",
|
2017-12-06 09:56:49 -05:00
|
|
|
"//packages/router",
|
|
|
|
|
"//packages/router/testing",
|
2019-10-05 23:06:53 -04:00
|
|
|
"//packages/zone.js/lib:zone_d_ts",
|
2019-02-20 12:54:42 -05:00
|
|
|
"@npm//rxjs",
|
2017-12-06 09:56:49 -05:00
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
2017-12-16 14:35:47 -05:00
|
|
|
ts_library(
|
|
|
|
|
name = "test_node_only_lib",
|
2018-10-16 02:24:22 -04:00
|
|
|
testonly = True,
|
2017-12-16 14:35:47 -05:00
|
|
|
srcs = glob(["**/*_node_only_spec.ts"]),
|
|
|
|
|
deps = [
|
|
|
|
|
":test_lib",
|
|
|
|
|
"//packages/compiler",
|
|
|
|
|
"//packages/compiler/testing",
|
|
|
|
|
"//packages/core",
|
2019-02-08 17:10:20 -05:00
|
|
|
"//packages/core/src/compiler",
|
2017-12-16 14:35:47 -05:00
|
|
|
"//packages/core/testing",
|
|
|
|
|
"//packages/platform-server",
|
|
|
|
|
"//packages/platform-server/testing",
|
2018-11-05 23:31:54 -05:00
|
|
|
"//packages/private/testing",
|
2017-12-16 14:35:47 -05:00
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
2017-12-06 09:56:49 -05:00
|
|
|
jasmine_node_test(
|
|
|
|
|
name = "test",
|
2020-01-08 02:56:49 -05:00
|
|
|
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",
|
|
|
|
|
],
|
2019-03-08 19:35:36 -05:00
|
|
|
shard_count = 4,
|
2017-12-16 14:35:47 -05:00
|
|
|
deps = [
|
|
|
|
|
":test_lib",
|
|
|
|
|
":test_node_only_lib",
|
|
|
|
|
"//packages/platform-server",
|
|
|
|
|
"//packages/platform-server/testing",
|
2019-10-05 23:06:53 -04:00
|
|
|
"//packages/zone.js/lib:zone_d_ts",
|
2019-02-20 12:54:42 -05:00
|
|
|
"@npm//base64-js",
|
|
|
|
|
"@npm//source-map",
|
2017-12-16 14:35:47 -05:00
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
2019-11-13 12:08:38 -05:00
|
|
|
karma_web_test_suite(
|
2017-12-16 14:35:47 -05:00
|
|
|
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"],
|
2017-12-06 09:56:49 -05:00
|
|
|
deps = [
|
|
|
|
|
":test_lib",
|
|
|
|
|
],
|
|
|
|
|
)
|
