angular-cn/packages/compiler-cli/BUILD.bazel

66 lines
1.9 KiB
Python
Raw Normal View History

package(default_visibility = ["//visibility:public"])
load("//tools:defaults.bzl", "npm_package", "ts_library")
load("@npm_bazel_typescript//:index.bzl", "ts_config")
ts_config(
name = "tsconfig",
src = "tsconfig-build.json",
deps = ["//packages:tsconfig-build.json"],
)
ts_library(
name = "compiler-cli",
srcs = glob(
[
"*.ts",
"src/**/*.ts",
],
exclude = [
"src/integrationtest/**/*.ts",
],
),
tsconfig = ":tsconfig",
deps = [
"//packages/compiler",
"//packages/compiler-cli/src/ngtsc/annotations",
"//packages/compiler-cli/src/ngtsc/cycles",
"//packages/compiler-cli/src/ngtsc/diagnostics",
"//packages/compiler-cli/src/ngtsc/entry_point",
"//packages/compiler-cli/src/ngtsc/imports",
"//packages/compiler-cli/src/ngtsc/partial_evaluator",
feat(ivy): use fileNameToModuleName to emit imports when it's available (#28523) The ultimate goal of this commit is to make use of fileNameToModuleName to get the module specifier to use when generating an import, when that API is available in the CompilerHost that ngtsc is created with. As part of getting there, the way in which ngtsc tracks references and generates import module specifiers is refactored considerably. References are tracked with the Reference class, and previously ngtsc had several different kinds of Reference. An AbsoluteReference represented a declaration which needed to be imported via an absolute module specifier tracked in the AbsoluteReference, and a RelativeReference represented a declaration from the local program, imported via relative path or referred to directly by identifier if possible. Thus, how to refer to a particular declaration was encoded into the Reference type _at the time of creation of the Reference_. This commit refactors that logic and reduces Reference to a single class with no subclasses. A Reference represents a node being referenced, plus context about how the node was located. This context includes a "bestGuessOwningModule", the compiler's best guess at which absolute module specifier has defined this reference. For example, if the compiler arrives at the declaration of CommonModule via an import to @angular/common, then any references obtained from CommonModule (e.g. NgIf) will also be considered to be owned by @angular/common. A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface are introduced. To produce an Expression referring to a given Reference'd node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy implementations. Several different strategies are defined: - LocalIdentifierStrategy: use local ts.Identifiers if available. - AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule, import the node via an absolute import from that module specifier. - LogicalProjectStrategy: if the Reference is in the logical project (is under the project rootDirs), import the node via a relative import. - FileToModuleStrategy: use a FileToModuleHost to generate the module specifier by which to import the node. Depending on the availability of fileNameToModuleName in the CompilerHost, then, a different collection of these strategies is used for compilation. PR Close #28523
2019-02-01 20:24:21 -05:00
"//packages/compiler-cli/src/ngtsc/path",
"//packages/compiler-cli/src/ngtsc/reflection",
"//packages/compiler-cli/src/ngtsc/routing",
"//packages/compiler-cli/src/ngtsc/scope",
"//packages/compiler-cli/src/ngtsc/shims",
refactor(ivy): obviate the Bazel component of the ivy_switch (#26550) Originally, the ivy_switch mechanism used Bazel genrules to conditionally compile one TS file or another depending on whether ngc or ngtsc was the selected compiler. This was done because we wanted to avoid importing certain modules (and thus pulling them into the build) if Ivy was on or off. This mechanism had a major drawback: ivy_switch became a bottleneck in the import graph, as it both imports from many places in the codebase and is imported by many modules in the codebase. This frequently resulted in cyclic imports which caused issues both with TS and Closure compilation. It turns out ngcc needs both code paths in the bundle to perform the switch during its operation anyway, so import switching was later abandoned. This means that there's no real reason why the ivy_switch mechanism needed to operate at the Bazel level, and for the ivy_switch file to be a bottleneck. This commit removes the Bazel-level ivy_switch mechanism, and introduces an additional TypeScript transform in ngtsc (and the pass-through tsc compiler used for testing JIT) to perform the same operation that ngcc does, and flip the switch during ngtsc compilation. This allows the ivy_switch file to be removed, and the individual switches to be located directly next to their consumers in the codebase, greatly mitigating the circular import issues and making the mechanism much easier to use. As part of this commit, the tag for marking switched variables was changed from __PRE_NGCC__ to __PRE_R3__, since it's no longer just ngcc which flips these tags. Most variables were renamed from R3_* to SWITCH_* as well, since they're referenced mostly in render2 code. Test strategy: existing test coverage is more than sufficient - if this didn't work correctly it would break the hello world and todo apps. PR Close #26550
2018-10-17 18:44:44 -04:00
"//packages/compiler-cli/src/ngtsc/switch",
"//packages/compiler-cli/src/ngtsc/transform",
"//packages/compiler-cli/src/ngtsc/typecheck",
"//packages/compiler-cli/src/ngtsc/util",
"@npm//@bazel/typescript",
"@npm//@types",
"@npm//tsickle",
"@npm//typescript",
],
)
npm_package(
name = "npm_package",
srcs = [
"package.json",
],
tags = [
"release-with-framework",
],
# Do not add more to this list.
# Dependencies on the full npm_package cause long re-builds.
visibility = [
"//packages/compiler-cli/integrationtest:__pkg__",
],
deps = [
":compiler-cli",
"//packages/compiler-cli/ngcc",
],
)