angular-docs-cn/packages/platform-server/BUILD.bazel

62 lines
1.6 KiB
Python
Raw Normal View History

load("//tools:defaults.bzl", "api_golden_test_npm_package", "ng_module", "ng_package")
package(default_visibility = ["//visibility:public"])
ng_module(
name = "platform-server",
srcs = glob(
[
"*.ts",
"src/**/*.ts",
],
),
deps = [
"//packages/animations/browser",
"//packages/common",
"//packages/common/http",
"//packages/compiler",
"//packages/core",
"//packages/platform-browser",
"//packages/platform-browser-dynamic",
"//packages/platform-browser/animations",
"//packages/zone.js/lib:zone_d_ts",
"@npm//@types/node",
"@npm//domino",
"@npm//rxjs",
],
)
ng_package(
name = "npm_package",
srcs = [
"package.json",
feat(platform-server): allow shimming the global env sooner (#40559) `@angular/platform-server` provides the foundation for rendering an Angular app on the server. In order to achieve that, it uses a server-side DOM implementation (currently [domino][1]). For rendering on the server to work as closely as possible to running the app on the browser, we need to make DOM globals (such as `Element`, `HTMLElement`, etc.), which are normally provided by the browser, available as globals on the server as well. Currently, `@angular/platform-server` achieves this by extending the `global` object with the DOM implementation provided by `domino`. This assignment happens in the [setDomTypes()][2] function, which is [called in a `PLATFORM_INITIALIZER`][3]. While this works in most cases, there are some scenarios where the DOM globals are needed sooner (i.e. before initializing the platform). See, for example, #24551 and #39950 for more details on such issues. This commit provides a way to solve this problem by exposing a side-effect-ful entry-point (`@angular/platform-server/init`), that shims the `global` object with DOM globals. People will be able to import this entry-point in their server-rendered apps before bootstrapping the app (for example, in their `main.server.ts` file). (See also [#39950 (comment)][4].) In a future update, the [`universal` schematics][5] will include such an import by default in newly generated projects. [1]: https://www.npmjs.com/package/domino [2]: https://github.com/angular/angular/blob/0fc8466f1be392917e0c/packages/platform-server/src/domino_adapter.ts#L17-L21 [3]: https://github.com/angular/angular/blob/0fc8466f1be392917e0c/packages/platform-server/src/server.ts#L33 [4]: https://github.com/angular/angular/issues/39950#issuecomment-747598403 [5]: https://github.com/angular/angular-cli/blob/cc51432661eb4ab4b6a3/packages/schematics/angular/universal PR Close #40559
2021-02-11 12:24:52 -05:00
"//packages/platform-server/init:package.json",
"//packages/platform-server/testing:package.json",
],
entry_point = ":index.ts",
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/compiler-cli/integrationtest:__pkg__",
],
deps = [
":platform-server",
feat(platform-server): allow shimming the global env sooner (#40559) `@angular/platform-server` provides the foundation for rendering an Angular app on the server. In order to achieve that, it uses a server-side DOM implementation (currently [domino][1]). For rendering on the server to work as closely as possible to running the app on the browser, we need to make DOM globals (such as `Element`, `HTMLElement`, etc.), which are normally provided by the browser, available as globals on the server as well. Currently, `@angular/platform-server` achieves this by extending the `global` object with the DOM implementation provided by `domino`. This assignment happens in the [setDomTypes()][2] function, which is [called in a `PLATFORM_INITIALIZER`][3]. While this works in most cases, there are some scenarios where the DOM globals are needed sooner (i.e. before initializing the platform). See, for example, #24551 and #39950 for more details on such issues. This commit provides a way to solve this problem by exposing a side-effect-ful entry-point (`@angular/platform-server/init`), that shims the `global` object with DOM globals. People will be able to import this entry-point in their server-rendered apps before bootstrapping the app (for example, in their `main.server.ts` file). (See also [#39950 (comment)][4].) In a future update, the [`universal` schematics][5] will include such an import by default in newly generated projects. [1]: https://www.npmjs.com/package/domino [2]: https://github.com/angular/angular/blob/0fc8466f1be392917e0c/packages/platform-server/src/domino_adapter.ts#L17-L21 [3]: https://github.com/angular/angular/blob/0fc8466f1be392917e0c/packages/platform-server/src/server.ts#L33 [4]: https://github.com/angular/angular/issues/39950#issuecomment-747598403 [5]: https://github.com/angular/angular-cli/blob/cc51432661eb4ab4b6a3/packages/schematics/angular/universal PR Close #40559
2021-02-11 12:24:52 -05:00
"//packages/platform-server/init",
"//packages/platform-server/testing",
],
)
api_golden_test_npm_package(
name = "platform-server_api",
data = [
":npm_package",
"//goldens:public-api",
],
golden_dir = "angular/goldens/public-api/platform-server",
npm_package = "angular/packages/platform-server/npm_package",
)