Several updates to Angular Package Format.
BREAKING CHANGE:
Several changes to the Angular Package Format (APF)
- Removal of FESM2015
- Replacing ES2020 with ES2022
- Replacing FESM2020 with FESM2022
PR Close#49559
Several updates to Angular Package Format.
BREAKING CHANGE:
Several changes to the Angular Package Format (APF)
- Removal of FESM2015
- Replacing ES2020 with ES2022
- Replacing FESM2020 with FESM2022
PR Close#49332
The options to generate NgFactory and NgSummary files were added to Ivy for backwards compatibility with ViewEngine. Since ViewEngine was deprecated and removed, the NgFactory and NgSummary files are no longer used as well.
This commit drops obsolete options to generate NgFactory and NgSummary files. Also, the logic that generates those files is also removed.
PR Close#48268
This is basically a pre-step for combining devmode and prodmode into a
single compilation. We are already achieving this now, and can claim
with confidence that we reduced possible actions by half. This is
especially important now that prodmode is used more often, but rules
potentially still using the devmode ESM sources. We can avoid double
compilations (which existed before the whole ESM migration too!).
We will measure this more when we have more concrete documentation
of the changes & a better planning document.
Changes:
* ts_library will no longer generate devmode `d.ts`. Definitions are
generated as part of prodmode. That way only prodmode can be exposed
via providers.
* applied the same to `ng_module`.
* updates migrations to bundle because *everything* using `ts_library`
is now ESM. This is actually also useful in the future if
schematics rely on e.g. the compiler.
* updates schematics for localize to also bundle. similar reason as
above.
PR Close#48521
Currently the devmode output for `ng_module` and `ts_library` is
using ES5 CommonJS UMD. To bring it in sync with prodmode and
to start with our long-term migration to full ESM- the devmode
is updated to to ES2020 ES modules too.
This will require more tricks to make devmod work with the bazel
setup and also tests may need to be refactored given them relying
on ES5 CJS features, like for `spyOn` jasmine patching etc.
PR Close#48521
Speeds up the dev-turnaround by only bundling types when packaging. Currently
bundling occurs for all the `ng_module` targets in devmode.
This has various positive benefits:
* Avoidance of this rather slower operation in development
* Makes APF-built packages also handle types for `ts_library` targets consistently.
* Allows us to ensure APF entry-points have `d.ts` _always_ bundled (working with ESM
module resolution in TypeScript -- currently experimental)
* Allows us to remove the secondary `package.json` files from APF (maybe APF v14? - seems
low-impact). This would clean-up the APF even more and fix resolution issues (like in Vite)
PR Close#45405
We updated buildifier and a few warnings became errors now. This commit
cleans up the failing unused variable instances, making the linter happy.
Additionally for the API extractor BUILD file, the package defaults
need to move to satisfy buildifier.
PR Close#45431
As mentioned in previous commits (check them for more details), `@bazel/typescript`
no longer contains `ts_library`-specific code, so we no longer need that dependency.
PR Close#45431
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
We should no longer generate VE shims for workspaces which are not named
`angular`. The default is Ivy compilation and this should be opt-in. The
components repository for example does not need any shims as it is using
Ivy for the common development workflows.
PR Close#43431
Previously, the prodmode output was using ES2015 for `ng_module` and
`ts_library` targets. This commit changes it to `ES2020`. This is
necessary as we want to ship es2020 output in APF v13.
PR Close#43431
In preparation for using the partial compilation transition on the
packager, we need to be able to have a reference to the flat module
out file (that is used as "index" file for entry-point ng_module targets).
We need a reference to the file because with transitions applied, the
inputs are not necessarily in the default `bazel-out` directory. The
packager currently only guesses such paths (this worked most of the
time) but guessing the output directory with transitions will become
impossible.. so the paths need to be computed in a Bazel-idiomatic way.
This is more future-proof and correct (and more clean IMO).
PR Close#43431
Removes the `compilation_mode` attribute for the `ng_module` rule. We
remove the attribute since we intend to control the compilation mode
through the partial compilation build setting we have added before.
Note: We could have named the build setting more generically, something
like `ng_compilation_mode`, but I think it's more readable only assuming
there is `partial` compilation, or `full`. We can always change this in
the future as it is not part of the public API.
PR Close#43431
Previously, `ng_module` generated a second `d.ts` bundle in case the
built target was the Angular core target. This was done so that the
packager later on can ship the `r3_symbols.d.ts` file along with the
APF v13 output. Ngcc relied on this file when it processed the Angular
core package. This is no longer needed for Angular Core v13 since it
will come as partially-compiled without the need for ngcc.
The major benefit of no longer generating multiple dts files here is
that we can reasonably pass the bundle through a provider to the packager
which can then use this for determining the `d.ts` file it should link
in the `package.json`.
This is beneficial and needed for using a transition since the packager
input files are no longer in the default `bazel-out`, so it's important
to keep an reference to the actual Bazel `<File>` instance, allowing
us to determine the path properly in the packager (without any
assumptions on the `bazel-out` path..).
PR Close#43431
We created a build setting (bool flag) for controlling whether partial
compilation should be enabled or not. This commit wires up the build
setting so that all `ng_module` targets respect the flag.
This will later be useful when we apply the transition (which always
sets the partial compilation flag to `True`).
PR Close#43431
Moves the `ng_module.bzl` file into a sub-directory called `ng_module`.
This is consistent with other rules in the package. And it also allows
us to ship the `ng_module.bzl` code next to other tightly-coupled files
like the partial compilation transition/flag.
PR Close#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
