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

49 lines
1.1 KiB
Python
Raw Normal View History

load("//tools:defaults.bzl", "ng_package", "ts_api_guardian_test_npm_package", "ts_library")
package(default_visibility = ["//visibility:public"])
ts_library(
name = "localize",
srcs = glob(
[
"*.ts",
"src/**/*.ts",
],
),
module_name = "@angular/localize",
deps = [
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 07:51:30 -04:00
"//packages/localize/src/localize",
"//packages/localize/src/utils",
],
)
ng_package(
name = "npm_package",
srcs = [
"package.json",
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 07:51:30 -04:00
"//packages/localize/init:package.json",
],
entry_point = ":index.ts",
nested_packages = [
"//packages/localize/schematics:npm_package",
"//packages/localize/src/tools:npm_package",
],
tags = [
"release-with-framework",
],
deps = [
":localize",
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 07:51:30 -04:00
"//packages/localize/init",
],
)
ts_api_guardian_test_npm_package(
name = "localize_api",
build: provide full paths to `ts_api_guardian_test_npm_package` and `ts_api_guardian_test` (#36034) ts-api-guardian uses `require.resolve` to resolve the actual and golden files under bazel. In Windows for these files to be resolved correct the full path including the workspace name as per the MANIFEST entries is required. This used to be the case until the recent changes done to use npm_integration tests https://github.com/angular/angular/blob/83c74ceacf620535673ec141fc8a1003aed187ef/tools/public_api_guard/public_api_guard.bzl#L19 https://github.com/angular/angular/blob/83c74ceacf620535673ec141fc8a1003aed187ef/tools/public_api_guard/public_api_guard.bzl#L28 ``` bazel test //packages/... --test_tag_filters=api_guard //packages/animations:animations_api (cached) PASSED in 18.4s //packages/common:common_api (cached) PASSED in 25.5s //packages/compiler-cli:compiler_options_api (cached) PASSED in 12.4s //packages/compiler-cli:error_code_api (cached) PASSED in 11.6s //packages/core:core_api (cached) PASSED in 20.6s //packages/core:ng_global_utils_api (cached) PASSED in 13.5s //packages/elements:elements_api (cached) PASSED in 11.9s //packages/forms:forms_api (cached) PASSED in 13.9s //packages/http:http_api (cached) PASSED in 14.8s //packages/localize:localize_api (cached) PASSED in 6.3s //packages/platform-browser:platform-browser_api (cached) PASSED in 18.1s //packages/platform-browser-dynamic:platform-browser-dynamic_api (cached) PASSED in 14.0s //packages/platform-server:platform-server_api (cached) PASSED in 13.9s //packages/platform-webworker:platform-webworker_api (cached) PASSED in 13.7s //packages/platform-webworker-dynamic:platform-webworker-dynamic_api (cached) PASSED in 11.7s //packages/router:router_api (cached) PASSED in 19.9s //packages/service-worker:service-worker_api (cached) PASSED in 18.1s //packages/upgrade:upgrade_api (cached) PASSED in 13.5s ``` Reference: DEV-71 PR Close #36034
2020-03-12 07:36:28 -04:00
actualDir = "angular/packages/localize/npm_package",
data = [
":npm_package",
"//goldens:public-api",
],
build: provide full paths to `ts_api_guardian_test_npm_package` and `ts_api_guardian_test` (#36034) ts-api-guardian uses `require.resolve` to resolve the actual and golden files under bazel. In Windows for these files to be resolved correct the full path including the workspace name as per the MANIFEST entries is required. This used to be the case until the recent changes done to use npm_integration tests https://github.com/angular/angular/blob/83c74ceacf620535673ec141fc8a1003aed187ef/tools/public_api_guard/public_api_guard.bzl#L19 https://github.com/angular/angular/blob/83c74ceacf620535673ec141fc8a1003aed187ef/tools/public_api_guard/public_api_guard.bzl#L28 ``` bazel test //packages/... --test_tag_filters=api_guard //packages/animations:animations_api (cached) PASSED in 18.4s //packages/common:common_api (cached) PASSED in 25.5s //packages/compiler-cli:compiler_options_api (cached) PASSED in 12.4s //packages/compiler-cli:error_code_api (cached) PASSED in 11.6s //packages/core:core_api (cached) PASSED in 20.6s //packages/core:ng_global_utils_api (cached) PASSED in 13.5s //packages/elements:elements_api (cached) PASSED in 11.9s //packages/forms:forms_api (cached) PASSED in 13.9s //packages/http:http_api (cached) PASSED in 14.8s //packages/localize:localize_api (cached) PASSED in 6.3s //packages/platform-browser:platform-browser_api (cached) PASSED in 18.1s //packages/platform-browser-dynamic:platform-browser-dynamic_api (cached) PASSED in 14.0s //packages/platform-server:platform-server_api (cached) PASSED in 13.9s //packages/platform-webworker:platform-webworker_api (cached) PASSED in 13.7s //packages/platform-webworker-dynamic:platform-webworker-dynamic_api (cached) PASSED in 11.7s //packages/router:router_api (cached) PASSED in 19.9s //packages/service-worker:service-worker_api (cached) PASSED in 18.1s //packages/upgrade:upgrade_api (cached) PASSED in 13.5s ``` Reference: DEV-71 PR Close #36034
2020-03-12 07:36:28 -04:00
goldenDir = "angular/goldens/public-api/localize",
)