honeymoose/angular-cn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
angular-cn/packages/bazel/src/api-extractor/BUILD.bazel

35 lines
702 B
Python
Raw Normal View History

build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727) 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. @josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial. PR Close #37727
2020-06-25 01:32:41 -07:00
# BEGIN-DEV-ONLY
feat(bazel): add dts bundler as action to ng_module (#28588) This enabled dts flattening in the final distrubutable package. Notes: - For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default. - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029 Ref: TOOL-611 PR Close #28588
2019-02-07 19:02:07 +01:00
package(default_visibility = ["//packages:__subpackages__"])
load("//tools:defaults.bzl", "ts_library")
build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727) 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. @josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial. PR Close #37727
2020-06-25 01:32:41 -07:00
load("@build_bazel_rules_nodejs//:index.bzl", "nodejs_binary")
feat(bazel): add dts bundler as action to ng_module (#28588) This enabled dts flattening in the final distrubutable package. Notes: - For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default. - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029 Ref: TOOL-611 PR Close #28588
2019-02-07 19:02:07 +01:00
ts_library(
name = "lib",
srcs = [
"index.ts",
],
deps = [
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 09:54:42 -08:00
"@npm//@bazel/typescript",
"@npm//@microsoft/api-extractor",
"@npm//@types/node",
feat(bazel): add dts bundler as action to ng_module (#28588) This enabled dts flattening in the final distrubutable package. Notes: - For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default. - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029 Ref: TOOL-611 PR Close #28588
2019-02-07 19:02:07 +01:00
],
)
nodejs_binary(
name = "api_extractor",
data = [
":lib",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 09:54:42 -08:00
"@npm//@bazel/typescript",
"@npm//@microsoft/api-extractor",
feat(bazel): add dts bundler as action to ng_module (#28588) This enabled dts flattening in the final distrubutable package. Notes: - For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default. - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029 Ref: TOOL-611 PR Close #28588
2019-02-07 19:02:07 +01:00
],
build: convert entry_point to label (#30627) PR Close #30627
2019-06-07 13:38:06 -07:00
entry_point = ":index.ts",
feat(bazel): add dts bundler as action to ng_module (#28588) This enabled dts flattening in the final distrubutable package. Notes: - For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default. - This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029 Ref: TOOL-611 PR Close #28588
2019-02-07 19:02:07 +01:00
visibility = ["//visibility:public"],
)
build: Add .bzl/BUILD files to @angular/bazel package (#28769) It's now possible to use it as a hybrid package in latest rules_nodejs, so no WORKSPACE dep is needed PR Close #28769
2019-02-19 16:15:06 -08:00
filegroup(
name = "package_assets",
srcs = ["BUILD.bazel"],
)
build: upgrade angular build, integration/bazel and @angular/bazel package to rule_nodejs 2.2.0 (#37727) 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. @josephperrott, this touches `packages/bazel/src/external.bzl` which will make the sync to g3 non-trivial. PR Close #37727
2020-06-25 01:32:41 -07:00
# END-DEV-ONLY
Reference in New Issue Copy Permalink