2017-12-06 09:56:49 -05:00
|
|
|
package(default_visibility = ["//visibility:public"])
|
|
|
|
|
|
2020-02-26 12:09:35 -05:00
|
|
|
load("//tools:defaults.bzl", "pkg_npm", "ts_api_guardian_test", "ts_library")
|
2019-02-20 12:54:42 -05:00
|
|
|
load("@npm_bazel_typescript//:index.bzl", "ts_config")
|
2017-09-25 15:40:22 -04:00
|
|
|
|
|
|
|
|
ts_config(
|
|
|
|
|
name = "tsconfig",
|
|
|
|
|
src = "tsconfig-build.json",
|
2017-12-06 09:56:49 -05:00
|
|
|
deps = ["//packages:tsconfig-build.json"],
|
2017-09-25 15:40:22 -04:00
|
|
|
)
|
2017-07-21 17:20:34 -04:00
|
|
|
|
|
|
|
|
ts_library(
|
|
|
|
|
name = "compiler-cli",
|
2017-12-06 09:56:49 -05:00
|
|
|
srcs = glob(
|
|
|
|
|
[
|
|
|
|
|
"*.ts",
|
|
|
|
|
"src/**/*.ts",
|
|
|
|
|
],
|
2017-12-18 00:36:21 -05:00
|
|
|
exclude = [
|
|
|
|
|
"src/integrationtest/**/*.ts",
|
|
|
|
|
],
|
2017-12-06 09:56:49 -05:00
|
|
|
),
|
|
|
|
|
tsconfig = ":tsconfig",
|
2017-07-21 17:20:34 -04:00
|
|
|
deps = [
|
2017-12-06 09:56:49 -05:00
|
|
|
"//packages/compiler",
|
2020-01-17 19:00:07 -05:00
|
|
|
"//packages/compiler-cli/src/ngtsc/core",
|
|
|
|
|
"//packages/compiler-cli/src/ngtsc/core:api",
|
2018-08-23 17:33:38 -04:00
|
|
|
"//packages/compiler-cli/src/ngtsc/diagnostics",
|
2019-06-06 15:22:32 -04:00
|
|
|
"//packages/compiler-cli/src/ngtsc/file_system",
|
2019-06-10 12:19:35 -04:00
|
|
|
"//packages/compiler-cli/src/ngtsc/indexer",
|
2019-03-18 14:16:38 -04:00
|
|
|
"//packages/compiler-cli/src/ngtsc/perf",
|
fix(compiler-cli): downlevel angular decorators to static properties (#37382)
In v7 of Angular we removed `tsickle` from the default `ngc` pipeline.
This had the negative potential of breaking ES2015 output and SSR due
to a limitation in TypeScript.
TypeScript by default preserves type information for decorated constructor
parameters when `emitDecoratorMetadata` is enabled. For example,
consider this snippet below:
```
@Directive()
export class MyDirective {
constructor(button: MyButton) {}
}
export class MyButton {}
```
TypeScript would generate metadata for the `MyDirective` class it has
a decorator applied. This metadata would be needed in JIT mode, or
for libraries that provide `MyDirective` through NPM. The metadata would
look as followed:
```
let MyDirective = class MyDir {}
MyDirective = __decorate([
Directive(),
__metadata("design:paramtypes", [MyButton]),
], MyDirective);
let MyButton = class MyButton {}
```
Notice that TypeScript generated calls to `__decorate` and
`__metadata`. These calls are needed so that the Angular compiler
is able to determine whether `MyDirective` is actually an directive,
and what types are needed for dependency injection.
The limitation surfaces in this concrete example because `MyButton`
is declared after the `__metadata(..)` call, while `__metadata`
actually directly references `MyButton`. This is illegal though because
`MyButton` has not been declared at this point. This is due to the
so-called temporal dead zone in JavaScript. Errors like followed will
be reported at runtime when such file/code evaluates:
```
Uncaught ReferenceError: Cannot access 'MyButton' before initialization
```
As noted, this is a TypeScript limitation because ideally TypeScript
shouldn't evaluate `__metadata`/reference `MyButton` immediately.
Instead, it should defer the reference until `MyButton` is actually
declared. This limitation will not be fixed by the TypeScript team
though because it's a limitation as per current design and they will
only revisit this once the tc39 decorator proposal is finalized
(currently stage-2 at time of writing).
Given this wontfix on the TypeScript side, and our heavy reliance on
this metadata in libraries (and for JIT mode), we intend to fix this
from within the Angular compiler by downleveling decorators to static
properties that don't need to evaluate directly. For example:
```
MyDirective.ctorParameters = () => [MyButton];
```
With this snippet above, `MyButton` is not referenced directly. Only
lazily when the Angular runtime needs it. This mitigates the temporal
dead zone issue caused by a limitation in TypeScript's decorator
metadata output. See: https://github.com/microsoft/TypeScript/issues/27519.
In the past (as noted; before version 7), the Angular compiler by
default used tsickle that already performed this transformation. We
moved the transformation to the CLI for JIT and `ng-packager`, but now
we realize that we can move this all to a single place in the compiler
so that standalone ngc consumers can benefit too, and that we can
disable tsickle in our Bazel `ngc-wrapped` pipeline (that currently
still relies on tsickle to perform this decorator processing).
This transformation also has another positive side-effect of making
Angular application/library code more compatible with server-side
rendering. In principle, TypeScript would also preserve type information
for decorated class members (similar to how it did that for constructor
parameters) at runtime. This becomes an issue when your application
relies on native DOM globals for decorated class member types. e.g.
```
@Input() panelElement: HTMLElement;
```
Your application code would then reference `HTMLElement` directly
whenever the source file is loaded in NodeJS for SSR. `HTMLElement`
does not exist on the server though, so that will become an invalid
reference. One could work around this by providing global mocks for
these DOM symbols, but that doesn't match up with other places where
dependency injection is used for mocking DOM/browser specific symbols.
More context in this issue: #30586. The TL;DR here is that the Angular
compiler does not care about types for these class members, so it won't
ever reference `HTMLElement` at runtime.
Fixes #30106. Fixes #30586. Fixes #30141.
Resolves FW-2196. Resolves FW-2199.
PR Close #37382
2020-06-05 10:26:23 -04:00
|
|
|
"//packages/compiler-cli/src/ngtsc/reflection",
|
perf(compiler-cli): split Ivy template type-checking into multiple files (#36211)
As a performance optimization, this commit splits the single
__ngtypecheck__.ts file which was previously added to the user's program as
a container for all template type-checking code into multiple .ngtypecheck
shim files, one for each original file in the user's program.
In larger applications, the generation, parsing, and checking of this single
type-checking file was a huge performance bottleneck, with the file often
exceeding 1 MB in text content. Particularly in incremental builds,
regenerating this single file for the entire application proved especially
expensive.
This commit introduces a new strategy for template type-checking code which
makes use of a new interface, the `TypeCheckingProgramStrategy`. This
interface abstracts the process of creating a new `ts.Program` to type-check
a particular compilation, and allows the mechanism there to be kept separate
from the more complex logic around dealing with multiple .ngtypecheck files.
A new `TemplateTypeChecker` hosts that logic and interacts with the
`TypeCheckingProgramStrategy` to actually generate and return diagnostics.
The `TypeCheckContext` class, previously the workhorse of template type-
checking, is now solely focused on collecting and generating type-checking
file contents.
A side effect of implementing the new `TypeCheckingProgramStrategy` in this
way is that the API is designed to be suitable for use by the Angular
Language Service as well. The LS also needs to type-check components, but
has its own method for constructing a `ts.Program` with type-checking code.
Note that this commit does not make the actual checking of templates at all
_incremental_ just yet. That will happen in a future commit.
PR Close #36211
2020-03-04 18:50:12 -05:00
|
|
|
"//packages/compiler-cli/src/ngtsc/typecheck",
|
2019-02-20 12:54:42 -05:00
|
|
|
"@npm//@bazel/typescript",
|
2019-06-22 00:52:00 -04:00
|
|
|
"@npm//@types/node",
|
2020-02-12 05:52:15 -05:00
|
|
|
"@npm//chokidar",
|
2020-01-31 16:07:59 -05:00
|
|
|
"@npm//fs-extra",
|
2019-11-13 02:17:06 -05:00
|
|
|
"@npm//minimist",
|
2019-05-09 17:51:51 -04:00
|
|
|
"@npm//reflect-metadata",
|
2019-02-20 12:54:42 -05:00
|
|
|
"@npm//tsickle",
|
|
|
|
|
"@npm//typescript",
|
2017-07-21 17:20:34 -04:00
|
|
|
],
|
|
|
|
|
)
|
2018-03-13 14:00:53 -04:00
|
|
|
|
2019-12-28 19:37:59 -05:00
|
|
|
pkg_npm(
|
2018-03-13 14:00:53 -04:00
|
|
|
name = "npm_package",
|
|
|
|
|
srcs = [
|
|
|
|
|
"package.json",
|
|
|
|
|
],
|
2018-06-05 14:38:46 -04:00
|
|
|
tags = [
|
|
|
|
|
"release-with-framework",
|
|
|
|
|
],
|
2018-12-11 19:53:42 -05:00
|
|
|
# Do not add more to this list.
|
|
|
|
|
# Dependencies on the full npm_package cause long re-builds.
|
2019-01-22 12:46:51 -05:00
|
|
|
visibility = [
|
2020-02-04 14:45:40 -05:00
|
|
|
"//integration:__pkg__",
|
2019-01-22 12:46:51 -05:00
|
|
|
"//packages/compiler-cli/integrationtest:__pkg__",
|
|
|
|
|
],
|
2018-07-16 03:49:56 -04:00
|
|
|
deps = [
|
|
|
|
|
":compiler-cli",
|
2019-03-20 09:47:58 -04:00
|
|
|
"//packages/compiler-cli/ngcc",
|
2018-07-16 03:49:56 -04:00
|
|
|
],
|
2018-03-13 14:00:53 -04:00
|
|
|
)
|
2020-02-26 12:09:35 -05:00
|
|
|
|
|
|
|
|
ts_api_guardian_test(
|
|
|
|
|
name = "error_code_api",
|
2020-03-12 07:36:28 -04:00
|
|
|
actual = "angular/packages/compiler-cli/npm_package/src/ngtsc/diagnostics/src/error_code.d.ts",
|
2020-02-26 12:09:35 -05:00
|
|
|
data = [
|
|
|
|
|
":npm_package",
|
|
|
|
|
"//goldens:public-api",
|
|
|
|
|
],
|
2020-03-12 07:36:28 -04:00
|
|
|
golden = "angular/goldens/public-api/compiler-cli/error_code.d.ts",
|
2020-02-26 12:09:35 -05:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
ts_api_guardian_test(
|
|
|
|
|
name = "compiler_options_api",
|
2020-03-12 07:36:28 -04:00
|
|
|
actual = "angular/packages/compiler-cli/npm_package/src/ngtsc/core/api/src/public_options.d.ts",
|
2020-02-26 12:09:35 -05:00
|
|
|
data = [
|
|
|
|
|
":npm_package",
|
|
|
|
|
"//goldens:public-api",
|
|
|
|
|
],
|
2020-03-12 07:36:28 -04:00
|
|
|
golden = "angular/goldens/public-api/compiler-cli/compiler_options.d.ts",
|
2020-02-26 12:09:35 -05:00
|
|
|
)
|
