iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/dev-infra/bazel/BUILD.bazel

14 lines
344 B
Python
Raw Normal View History

refactor(dev-infra): ng_rollup_bundle rule should leverage `@bazel/rollup` (#37623) Refactors the `ng_rollup_bundle` rule to a macro that relies on the `@bazel/rollup` package. This means that the rule no longer deals with custom ESM5 flavour output, but rather only builds prodmode ES2015 output. This matches the common build output in Angular projects, and optimizations done in CLI where ES2015 is the default optimization input. The motiviation for this change is: * Not duplicating rollup Bazel rules. Instead leveraging the official rollup rule. * Not dealing with a third TS output flavor in Bazel.The ESM5 flavour has the potential of slowing down local development (as it requires compilation replaying) * Updating the rule to be aligned with current CLI optimizations. This also _fixes_ a bug that surfaced in the old rollup bundle rule. Code that is unused, is not removed properly. The new rule fixes this by setting the `toplevel` flag. This instructs terser to remove unused definitions at top-level. This matches the optimization applied in CLI projects. Notably the CLI doesn't need this flag, as code is always wrapped by Webpack. Hence, the unused code eliding runs by default. PR Close #37623
2020-06-17 04:37:36 -04:00
package(default_visibility = ["//visibility:public"])
fix(dev-infra): include `bazel` utility files in npm package (#37891) We recently added a new folder for common bazel utilities to `dev-infra`. The `ng_rollup_bundle` rule relies on an utility that is provided by this `bazel/` folder. Unfortunately though it looks like this folder is currently not included in the NPM package, so that the `ng_rollup_bundle` rule does not work as expected. This commit fixes that by including the bazel utilities in the NPM package. PR Close #37891
2020-07-02 08:45:23 -04:00
filegroup(
name = "files",
srcs = [
fix(dev-infra): add missing BUILD file to dev-infra/bazel:files (#38026) * Without this BUILD file we were seeing errors about the reference to expand_template.bzl in ng_rollup_bundle.bzl because dev-infra/bazel was not considered a package. PR Close #38026
2020-07-14 16:06:21 -04:00
"BUILD.bazel",
fix(dev-infra): include `bazel` utility files in npm package (#37891) We recently added a new folder for common bazel utilities to `dev-infra`. The `ng_rollup_bundle` rule relies on an utility that is provided by this `bazel/` folder. Unfortunately though it looks like this folder is currently not included in the NPM package, so that the `ng_rollup_bundle` rule does not work as expected. This commit fixes that by including the bazel utilities in the NPM package. PR Close #37891
2020-07-02 08:45:23 -04:00
"expand_template.bzl",
feat(dev-infra): add bazel rule for extracting JavaScript module flavors from targets (#42809) Introduces a rule that collects declared JavaScript module output files from a list of dependencies based on a configurable JavaScript module provider. The extracted outputs are exposed within the `DefaultInfo` provider. Targets defined using this rule can be used as input for rules that require JavaScript sources, or if there are multiple JavaScript output variants defined for a target while for example only the `JSModuleInfo` outputs are of interest. As an example: This rule is helpful in combination with `ts_library` and `ng_module` as those rule expose multiple output flavors (which are distinguishable by the JavaScript module providers as imported from `providers.bzl`). i.e. these rules expose flavors for named AMD modules and ECMAScript module output. If we want to ship a NPM package only using ECMAScript modules for example, we could extract all `JSEcmaScriptModuleInfo`-denoted output and feed that into the `pkg_npm` rule, compared to bringing in all output flavors. For reference: https://github.com/bazelbuild/rules_nodejs/blob/stable/packages/typescript/internal/build_defs.bzl#L334-L337 PR Close #42809
2021-07-09 14:22:50 -04:00
"extract_js_module_output.bzl",
feat(dev-infra): introduce shared tool for validating API signature (#42688) For the last years the Angular repositories relied on `ts-api-guardian` for testing the public API signature. This project worked well in general but its another inconvenience to maintain if we could rely on Microsoft's `api-extractor` tool. Especially since with TypeScript 4.3 issues with export aliases appeared that would require us to extend TS API guardian to support such exports. This is not as straightforward as it sounds, given it requires rewriting of declarations to show-case the proper name in the API golden. Microsoft's API extractor has integrated support for this. As of TypeScript 4.3, we want to start using the new `override` keyword. We are not able to use that keyword currently because an old version of API extractor is used in the `ng_module` rule to flatten the types into a single file. To fix this, we need to update `api-extractor`, but this unveils the issue with TS API guardian because the most recent version of api-extractor uses alias exports to avoid potential conflicts with globals available through the TypeScript default libraries (e.g. `dom.d.ts`). PR Close #42688
2021-06-28 13:40:33 -04:00
"//dev-infra/bazel/api-golden:files",
refactor(dev-infra): move shared browser bazel setup into dedicated bazel folder (#42268) This change moves the `dev-infra/browsers` folder into `dev-infra/bazel`. The browser folder is providing custom configuration for Bazel, so it should live within the `bazel` folder for a more well-structured `dev-infra` folder. PR Close #42268
2021-05-24 10:17:27 -04:00
"//dev-infra/bazel/browsers:files",
feat(dev-infra): create shared platform for remote execution (#41767) Introduces a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provide our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) PR Close #41767
2021-04-22 10:34:36 -04:00
"//dev-infra/bazel/remote-execution:files",
fix(dev-infra): include `bazel` utility files in npm package (#37891) We recently added a new folder for common bazel utilities to `dev-infra`. The `ng_rollup_bundle` rule relies on an utility that is provided by this `bazel/` folder. Unfortunately though it looks like this folder is currently not included in the NPM package, so that the `ng_rollup_bundle` rule does not work as expected. This commit fixes that by including the bazel utilities in the NPM package. PR Close #37891
2020-07-02 08:45:23 -04:00
],
)