2020-06-25 01:32:41 -07:00
|
|
|
# BEGIN-DEV-ONLY
|
2019-12-28 16:37:59 -08:00
|
|
|
load("//tools:defaults.bzl", "pkg_npm")
|
2018-03-07 09:04:27 -08:00
|
|
|
|
2019-12-28 16:37:59 -08:00
|
|
|
pkg_npm(
|
2018-03-07 09:04:27 -08:00
|
|
|
name = "npm_package",
|
2019-02-19 16:15:06 -08:00
|
|
|
srcs = glob(
|
|
|
|
|
["*"],
|
|
|
|
|
exclude = ["yarn.lock"],
|
|
|
|
|
) + [
|
2018-03-07 09:04:27 -08:00
|
|
|
"//packages/bazel/src:package_assets",
|
feat(bazel): create transition for enabling partial compilation (#43431)
Creates, a currently still unused, Bazel transition that will control
a build setting that is enabling the partial compilation mode for
`ng_module` rule targets. This is in preparation of implementing the
Angular Package Format v13 (which should ship in partial compilation).
Note: Various other approaches aside from the `transition` has been
considered. Here is a small summary of the largest ideas that have
been tried for the APF v13 partial compilation refactor.
**Using an aspect for partial compilation in `ng_package`**
Similar to how we had an aspect for ESM5 compilation in the past,
an aspect could be used to create partial compilation prodmode output
for packaging. The aspect would take the existing prodmode compilation
details and "replay" the compilation with a modified tsconfig that
enables partial compilation.
This _can_ work but requires lots of caution and is very prone to
issues. In order to avoid conflicts with the existing prodmode output,
the partial compilation outputs would need to be written to a
sub-directory. This makes module resolution extremely difficult when
`ng_package` creates the FESM bundles. Also it is difficult to merge
multiple of these aspect-compiled folders into a single one for exposing
the non-bundled ESM output. It becomes especially difficult to ensure
that such an aspect target will actually use the _correct_ dependency
type definition when compiled.
e.g. consider a case where a partial compiled target relies on another
Angular target. The dependency will be compiled partially first, but
the other target _needs_ to rely on the partial compilation `d.ts`
output of the dependency (and *NOT* the devmode `.d.ts` output). This
is incorrect and can cause other type-checking issues / or invalid
output. To make this work, the module resolution when invoking
tsc_wrapped would also need to be updated/patched. This is out of scope
and not reasonable to maintain.
**Exposing a third output flavor directly in the rule**
Instead of replying a compilation, we could expose an output flavor
next to `devmode` and `prodmode`. This sounded like the easiest
solution at first, but it will have the same problems as the aspect
approach (in terms of module resoltion and avoiding conflicts of files).
We cannot control how TS emits `.d.ts` or `.js` files (without patching
into the compiler host), so we would need to store the compilation
output in a sub-folder similar to the aspect.. resulting in the same
issues. This is do-able but would require module resolution to be
patched and we do not have control over `@bazel/typescript`. Also,
`@bazel/typescript` does not forsee a third output flavor, so that
logic would need to be changed significantly as well.
PR Close #43431
2021-09-27 23:56:23 +02:00
|
|
|
"//packages/bazel/src/ng_module:package_assets",
|
2022-03-21 12:24:52 +01:00
|
|
|
"//packages/bazel/src/types_bundle:package_assets",
|
2019-02-19 16:15:06 -08:00
|
|
|
"//packages/bazel/src/ng_package:package_assets",
|
|
|
|
|
"//packages/bazel/src/ngc-wrapped:package_assets",
|
|
|
|
|
"//packages/bazel/third_party/github.com/bazelbuild/bazel/src/main/protobuf:package_assets",
|
2018-03-07 09:04:27 -08:00
|
|
|
],
|
2019-12-28 16:37:59 -08:00
|
|
|
substitutions = {
|
2021-01-26 08:57:44 -08:00
|
|
|
"(#|//)\\s+BEGIN-DEV-ONLY[\\w\\W]+?(#|//)\\s+END-DEV-ONLY": "",
|
feat(bazel): create transition for enabling partial compilation (#43431)
Creates, a currently still unused, Bazel transition that will control
a build setting that is enabling the partial compilation mode for
`ng_module` rule targets. This is in preparation of implementing the
Angular Package Format v13 (which should ship in partial compilation).
Note: Various other approaches aside from the `transition` has been
considered. Here is a small summary of the largest ideas that have
been tried for the APF v13 partial compilation refactor.
**Using an aspect for partial compilation in `ng_package`**
Similar to how we had an aspect for ESM5 compilation in the past,
an aspect could be used to create partial compilation prodmode output
for packaging. The aspect would take the existing prodmode compilation
details and "replay" the compilation with a modified tsconfig that
enables partial compilation.
This _can_ work but requires lots of caution and is very prone to
issues. In order to avoid conflicts with the existing prodmode output,
the partial compilation outputs would need to be written to a
sub-directory. This makes module resolution extremely difficult when
`ng_package` creates the FESM bundles. Also it is difficult to merge
multiple of these aspect-compiled folders into a single one for exposing
the non-bundled ESM output. It becomes especially difficult to ensure
that such an aspect target will actually use the _correct_ dependency
type definition when compiled.
e.g. consider a case where a partial compiled target relies on another
Angular target. The dependency will be compiled partially first, but
the other target _needs_ to rely on the partial compilation `d.ts`
output of the dependency (and *NOT* the devmode `.d.ts` output). This
is incorrect and can cause other type-checking issues / or invalid
output. To make this work, the module resolution when invoking
tsc_wrapped would also need to be updated/patched. This is out of scope
and not reasonable to maintain.
**Exposing a third output flavor directly in the rule**
Instead of replying a compilation, we could expose an output flavor
next to `devmode` and `prodmode`. This sounded like the easiest
solution at first, but it will have the same problems as the aspect
approach (in terms of module resoltion and avoiding conflicts of files).
We cannot control how TS emits `.d.ts` or `.js` files (without patching
into the compiler host), so we would need to store the compilation
output in a sub-folder similar to the aspect.. resulting in the same
issues. This is do-able but would require module resolution to be
patched and we do not have control over `@bazel/typescript`. Also,
`@bazel/typescript` does not forsee a third output flavor, so that
logic would need to be changed significantly as well.
PR Close #43431
2021-09-27 23:56:23 +02:00
|
|
|
# The partial compilation transition is applied in the user workspace. We do not want to require
|
|
|
|
|
# users having to define the build setting, so we directly point the flag label to the place where
|
|
|
|
|
# we expect `@angular/bazel` being located. Note: This expects the `@npm//` workspace to be used.
|
|
|
|
|
"//packages/bazel/src:partial_compilation": "@npm//@angular/bazel/src:partial_compilation",
|
2022-03-21 12:24:52 +01:00
|
|
|
# Substitutions to account for label changes when `@angular/bazel` is consumed externally.
|
|
|
|
|
# NodeJS binaries are pre-built and should be consumed through the NPM bin scripts of the package.
|
|
|
|
|
"//packages/bazel/src/types_bundle:types_bundler": "@npm//@angular/bazel/bin:types_bundler",
|
2020-06-25 01:32:41 -07:00
|
|
|
"//packages/bazel/": "//@angular/bazel/",
|
2022-03-22 20:03:39 +01:00
|
|
|
"@npm//@bazel/concatjs/internal:": "//@bazel/concatjs/internal:",
|
2019-02-19 16:15:06 -08:00
|
|
|
},
|
2018-03-30 13:48:47 -07:00
|
|
|
tags = ["release-with-framework"],
|
2018-12-11 16:53:42 -08:00
|
|
|
# Do not add more to this list.
|
|
|
|
|
# Dependencies on the full npm_package cause long re-builds.
|
2021-11-20 17:09:10 +01:00
|
|
|
visibility = ["//integration:__subpackages__"],
|
2018-10-16 13:20:00 -07:00
|
|
|
deps = [
|
|
|
|
|
"//packages/bazel/src/ng_package:lib",
|
|
|
|
|
"//packages/bazel/src/ngc-wrapped:ngc_lib",
|
2022-03-21 12:24:52 +01:00
|
|
|
"//packages/bazel/src/types_bundle:lib",
|
2018-10-16 13:20:00 -07:00
|
|
|
],
|
2018-03-07 09:04:27 -08:00
|
|
|
)
|
2020-06-25 01:32:41 -07:00
|
|
|
# END-DEV-ONLY
|