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

102 lines
3.2 KiB
Python
Raw Normal View History

load("@build_bazel_rules_nodejs//:index.bzl", "generated_file_test")
load("//tools:defaults.bzl", "api_golden_test", "api_golden_test_npm_package", "ng_module", "ng_package")
load("//packages/common/locales:index.bzl", "generate_base_locale_file")
package(default_visibility = ["//visibility:public"])
# This generates the `src/i18n/locale_en.ts` file through the `generate-locales` tool. Since
# the base locale file is checked-in for Google3, we add a `generated_file_test` to ensure
# the checked-in file is up-to-date. To disambiguate from the test, we use a more precise target
# name here.
generate_base_locale_file(
name = "base_locale_file_generated",
output_file = "base_locale_file_generated.ts",
)
generated_file_test(
name = "base_locale_file",
src = "src/i18n/locale_en.ts",
generated = ":base_locale_file_generated",
)
ng_module(
name = "core",
srcs = glob(
[
"*.ts",
"src/**/*.ts",
],
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
),
deps = [
"//packages:types",
"//packages/core/src/compiler",
"//packages/core/src/di/interface",
"//packages/core/src/interface",
"//packages/core/src/reflection",
"//packages/core/src/util",
"//packages/localize",
"//packages/zone.js/lib:zone_d_ts",
"@npm//rxjs",
],
)
ng_package(
name = "npm_package",
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -04:00
srcs = [
"package.json",
"//packages/core/testing:package.json",
],
entry_point = ":index.ts",
nested_packages = [
"//packages/core/schematics:npm_package",
],
tags = [
"release-with-framework",
],
# Do not add more to this list.
# Dependencies on the full npm_package cause long re-builds.
visibility = [
build: add npm_integration_test && angular_integration_test (#33927) * it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context * test //integration:bazel_test and //integration:bazel-schematics_test exclusively * run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute ``` //integration:bazel-schematics_test PASSED in 317.2s //integration:bazel_test PASSED in 167.8s ``` * Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are: - cli-hello-world* - hello_world__closure * add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test @babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive. NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0 NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct. PR Close #33927
2020-02-04 14:45:40 -05:00
"//integration:__pkg__",
"//packages/bazel/test/ng_package:__pkg__",
"//packages/compiler-cli/integrationtest:__pkg__",
"//packages/compiler-cli/ngcc/test:__pkg__",
"//packages/compiler-cli/test:__pkg__",
"//packages/compiler-cli/test/diagnostics:__pkg__",
"//packages/compiler-cli/test/transformers:__pkg__",
"//packages/compiler/test:__pkg__",
"//packages/language-service/test:__pkg__",
],
deps = [
":core",
"//packages/core/testing",
],
)
api_golden_test_npm_package(
name = "core_api",
data = [
":npm_package",
"//goldens:public-api",
],
golden_dir = "angular/goldens/public-api/core",
npm_package = "angular/packages/core/npm_package",
)
api_golden_test(
name = "ng_global_utils_api",
data = [
"//goldens:public-api",
"//packages/core",
# Additional targets the entry-point indirectly resolves `.d.ts` source files from.
# These are transitive to `:core`, but need to be listed explicitly here as only
# transitive `JSModule` information is collected (missing the type definitions).
"//packages/core/src/compiler",
"//packages/core/src/di/interface",
"//packages/core/src/interface",
"//packages/core/src/reflection",
"//packages/core/src/util",
],
entry_point = "angular/packages/core/src/render3/global_utils_api.d.ts",
golden = "angular/goldens/public-api/core/global_utils.md",
)