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

19 lines
466 B
Python
Raw Normal View History

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#39182) Updates to rules_nodejs 2.2.0. This is the first major release in 7 months and includes a number of features as well as breaking changes. Release notes: https://github.com/bazelbuild/rules_nodejs/releases/tag/2.0.0 Features of note for angular/angular: * stdout/stderr/exit code capture; this could be potentially be useful * TypeScript (ts_project); a simpler tsc rule that ts_library that can be used in the repo where ts_library is too heavy weight Breaking changes of note for angular/angular: * loading custom rules from npm packages: `ts_library` is no longer loaded from `@npm_bazel_typescript//:index.bzl` (which no longer exists) but is now loaded from `@npm//@bazel/typescript:index.bzl` * with the loading changes above, `load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")` is no longer needed in the WORKSPACE which also means that yarn_install does not need to run unless building/testing a target that depends on @npm. In angular/angular this is a minor improvement as almost everything depends on @npm. * @angular/bazel package is also updated in this PR to support the new load location; Angular + Bazel users that require it for ng_package (ng_module is no longer needed in OSS with Angular 10) will need to load from `@npm//@angular/bazel:index.bzl`. I investigated if it was possible to maintain backward compatability for the old load location `@npm_angular_bazel` but it is not since the package itself needs to be updated to load from `@npm//@bazel/typescript:index.bzl` instead of `@npm_bazel_typescript//:index.bzl` as it depends on ts_library internals for ng_module. * runfiles.resolve will now throw instead of returning undefined to match behavior of node require Other changes in angular/angular: * integration/bazel has been updated to use both ng_module and ts_libary with use_angular_plugin=true. The latter is the recommended way for rules_nodejs users to compile Angular 10 with Ivy. Bazel + Angular ViewEngine is supported with @angular/bazel <= 9.0.5 and Angular <= 8. There is still Angular ViewEngine example on rules_nodejs https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_view_engine on these older versions but users that want to update to Angular 10 and are on Bazel must switch to Ivy and at that point ts_library with use_angular_plugin=true is more performant that ng_module. Angular example in rules_nodejs is configured this way as well: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular. As an aside, we also have an example of building Angular 10 with architect() rule directly instead of using ts_library with angular plugin: https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/angular_bazel_architect. NB: ng_module is still required for angular/angular repository as it still builds ViewEngine & @angular/bazel also provides the ng_package rule. ng_module can be removed in the future if ViewEngine is no longer needed in angular repo. * JSModuleInfo provider added to ng_module. this is for forward compat for future rules_nodejs versions. PR Close #39182
2020-06-25 04:32:41 -04:00
load("@npm//@bazel/typescript:index.bzl", "ts_library")
feat(dev-infra): create environment stamping script in ng-dev (#36844) Create a common environment stamping script in the ng-dev tooling as to be used in common release tasks. This is the first step in consolidating pieces of the release scripting process into a single location to develop a release tool. PR Close #36844
2020-04-20 17:44:25 -04:00
ts_library(
name = "release",
srcs = glob([
refactor(dev-infra): move existing env-stamp command into subfolder (#38656) Moves the existing `ng-dev release env-stamp` command into a subfolder so that the staging/publish tool can have its own dedicated folder (without being polluted by the env-stamp logic). Every subcommand should be in its own folder. PR Close #38656
2020-09-09 08:53:13 -04:00
"**/*.ts",
feat(dev-infra): create environment stamping script in ng-dev (#36844) Create a common environment stamping script in the ng-dev tooling as to be used in common release tasks. This is the first step in consolidating pieces of the release scripting process into a single location to develop a release tool. PR Close #36844
2020-04-20 17:44:25 -04:00
]),
module_name = "@angular/dev-infra-private/release",
visibility = ["//dev-infra:__subpackages__"],
deps = [
feat(dev-infra): add command for building release output (#38656) Adds a command for building all release packages. This command is primarily used by the release tool for building release output in version branches. The release tool cannot build the release packages configured in `master` as those packages could differ from the packages available in a given version branch. Also, the build process could have changed, so we want to have an API for building release packages that is guaranteed to be consistent across branches. PR Close #38656
2020-09-09 08:55:19 -04:00
"//dev-infra/release/build",
feat(dev-infra): tool for staging and publishing releases (#38656) Creates a tool for staging and publishing releases as per the new branching and versioning that has been outlined in the following document. The tool is intended to be used across the organization to ensure consistent branching/versioning and labeling: https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU/edit#heading=h.s3qlps8f4zq7dd The tool implements the actions as outlined in the following initial plan: https://hackmd.io/2Le8leq0S6G_R5VEVTNK9A. The implementation slightly diverged in so far that it performs staging and publishing together so that releasing is a single convenient command. In case of errors for which re-running the full command is not sufficient, we want to consider adding recover functionality. e.g. when the staging completed, but the actual NPM publishing aborted unexpectedly due to build errors. PR Close #38656
2020-09-09 09:01:18 -04:00
"//dev-infra/release/publish",
feat(dev-infra): add release command for setting NPM dist tag (#38656) Introduces a new command for `ng-dev release`, so that the NPM dist tag can be set for all configured NPM packages. This command can be useful in case a manual tag needs to be set, but it is primarily used by the release tooling when a new stable version is cut, and when the previous patch branch needs to be set as LTS version through a `v{major}-lts` dist tag. It is necessary to have this as a command so that the release tool can execute it for old branches where other packages might have been configured. This is similar to the separate `ng-dev build` command that we created. Note that we also added logic for spawning a process conveniently with different "console output" modes. This will be useful for other command invocations in the release tool and it's generally better than directly using native `child_process` as that one doesn't log to the dev-infra debug log file. PR Close #38656
2020-09-09 08:56:58 -04:00
"//dev-infra/release/set-dist-tag",
feat(dev-infra): migrate release tool to use new logging system (#37232) Migrate the release tool in ng-dev to use new logging system rather than directly calling console.* to create a better experience for users. PR Close #37232
2020-05-20 17:55:58 -04:00
"//dev-infra/utils",
feat(dev-infra): create environment stamping script in ng-dev (#36844) Create a common environment stamping script in the ng-dev tooling as to be used in common release tasks. This is the first step in consolidating pieces of the release scripting process into a single location to develop a release tool. PR Close #36844
2020-04-20 17:44:25 -04:00
"@npm//@types/yargs",
"@npm//yargs",
],
)