Instead of relying on Microsoft's API extractor for `d.ts` bundling,
we are switching to Rollup-based `.d.ts` bundling.
This allows us to support code spliting, even for `.d.ts` files,
allowing for relative imports to be used between entry-points, without
ending up duplicating `.d.ts` definitions in two files. This would otherwise cause
problems with assignability of types.
It also nicely integrates into our existing rollup configuration, and
overall simplifies the `ng_package` rule even further!
Notably `tsup` also uses this rollup plugin, and it seems to work well.
Keep in mind that Microsoft's API extractor is pretty hard to integrate,
caused many problems in the past, and isn't capable of code splitting.
This aligns our d.ts bundling with the .mjs bundling (great alignment).
PR Close#60321
PR Close#60332
Previously we never could use relative imports to import e.g. `Component`
in e.g. the `core/tests/bundling` folder. This was necessary because otherwise the
Angular compiler wouldn't process those files as it wouldn't recognize
the Angular decorator as the one from `@angular/core`.
Notably this still isn't a large issue because relative imports still
work for most core tests, that are JIT compiled!
For bundling tests though, or some smaller targets, our new upcoming
guidelines for using relative imports inside the full package; fall
apart. This commit unblocks this effort and allows us to use relative
imports in all tests of `packages/core`. This is achieved by leveraging
the existing `isCore` functionality of the compiler, and fixing a few
instances that were missing before.
PR Close#60268
Historically we've had to be VERY cautious about the way we import
things between entry-points. That is because the `ng_package` rule
bundling is subject to silently introducing code duplication, breaking
singletons etc. We've had this surface a couple of times already, and
dev-infra tried to help detect such cases by adding safety analysis into
`ng_package`.
Long-term we want to get to an approach where it's easy to simply share
code between chunks. Precisely, with the upcoming `rules_js` migration,
this will be necessary as we will have different import "guidelines"
that would currently, before this commit, result in code duplication, or
trigger our "safety check/lint".
This commit prepares `ng_package` to support relative imports between
entry-points, so that we only need the safety check for cross-package
imports/exports. The result is that `ng_package`/APF is now smartly able
to generate shared chunks for things that are needed between multiple
entry-points. Yay!
Note that those shared chunks still remain private, and are guarded by
our `package.json` "exports"; so no new public API surface is
exposed.
PR Close#60241
This is helpful as it allows us to set `type: module` in the checked-in
package files, useful for the hybrid mode of `rules_js` and
`rules_nodejs`, where the package.json files can control the execution
format.
PR Close#59406
`ts_project` interop does not emit `.mjs` files. We could achieve this
in the interop rule, but it's better to just fallback look for `.js`.
In addition, `ng_package` currently fails because there is no
`module_name` retrievable from the interop rule; hence causing in
incorrect packaging and safety errors being thrown.
PR Close#59325
Currently the module mapping aspect fails when it transitively discovers
a node module target managed by `rules_js`. That is because the targets
don't have a `deps` attribute as part of their rule definition.
PR Close#59316
When setting `"useDefineForClassFields": false`, static fields are compiled within a block that relies on the `this` context. This output makes it more difficult for bundlers to treeshake and eliminate unused code.
PR Close#58297
We have removed the `esm2022` directory from the generated package, as it was unused and contributed 7.7 MB to `@angular/core`. The `ng_package` rule still passes `esm2022` to the packager to perform `analyzeFileAndEnsureNoCrossImports`.
A moment of reflection:
You've always been there, full of potential, yet never called upon. Now, we bid you farewell.
PR Close#57559
Enables the new `@` block syntax by default by removing the `enabledBlockTypes` flags. There are still some internal flags that allow special use cases to opt out of the block syntax, like during XML parsing and when compiling older libraries (see #51979).
PR Close#51994
We control most flags via Starlark and therefore limit configuration
options via `tsconfig` to a minimum. We do not intend to support the
enabled block types option via Starlark, so this commit allows for
the option to be picked up.
(This is useful for benchmarking the new control flow blocks).
PR Close#51862
We were collecting all ES2022 files from entry-points (including
transitive files). Those are later on combined and filtered so that
we know which files to copy over to the package. There was no
deduping here. This did not have an effect, but could be a source
of slowness in `ng_package` and also breaks validation checks which
could show same errors multiple times for the same file.
PR Close#51500
Introduces a check into `ng_package` that will ensure that there are no
cross entry-point or cross-package relative imports that would end up
contributing to duplicate code. Not only would duplicate code result in
size increases, but also it could cause subtle hard-to-debug bugs,
especially when cross imports rely on e.g. singletons. Like for example
the deps tracker that is used in angular/core but also in
angular/core/testing.
PR Close#51500
`tsickle` is not used in any code paths in 3P and we can remove
this complexity. The `tsickle` npm package has not been released
in a while and we are risking breakages with e.g. future TypeScript
versions.
Note that the `ng_module` rule was updated to not emit through
tsickle at all. The tsickle in 1P is done directly by `tsc_wrapped`
and our code path in `compiler-cli` is not needed at all.
PR Close#50602
In local mode compilation the TS semantic check issues tons of diagnostics due to the fact that the file dependencies (.d.ts files) are not available in the program. So it needs to be disabled.
This commit should not cause any issue for the exsiting projects as it just removes a diagnostic in the local compilation mode.
PR Close#50486
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
Some 1P tools require to use the helper patchNgHostWithFileNameToModuleName, and the present location of this helper leads to circular depedency. So it is required to move this helper into a separate module to facilitate importing.
PR Close#48739
* updates ng-dev and build-tooling since the previous SHAs are
no longer existent after the CircleCI incident snapshot build removal.
* accounts for the new stamping variables.
PR Close#48731
This is no longer needed in google3 and actively impedes prodmode tests. See http://b/254054103#comment7 for deeper analysis.
This just turns off the transform for now, if it lands successfully I'll follow up with deleting the flag and dead code altogether.
PR Close#47934
Prior to this change the FESM bundles for the FW packages have the license banner duplicated hundreds of times in each published file.
With this change we remove all the banners from the individual input files. A new banner will be appended at the top of the FESM using rollup's banner option.
While there is a rollup plugin on NPM to strip these banners (https://github.com/mjeanroy/rollup-plugin-strip-banner) we could not use this as it does not support `.mjs`.
PR Close#48560
Fixes that we temporarily broke the Bazel npm package artifact as
part of the ESM work. This commit adjusts it and also makes the
artifact subsitutions more maintainable.
PR Close#48521
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
Since this repo will now be strict ESM, and Angular Compiler packages
on NPM are also ESM-only, we can rework `ngc-wrapped` to remove
the CJS/ESM interop and we make it strict ESM too.
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
No longer maintains a separate tsconfig for the Bazel package. This
seems to be a legacy artifact back when ngc-wrapped was put into GitHub.
We now use the canonical repository Bazel tsconfig. This commit also
fixes all strictness-related errors and makes ngc-wrapped compatible.
PR Close#47893
This option has no longer any effect as Ivy is the only rendering engine.
BREAKING CHANGE: Angular compiler option `enableIvy` has been removed as Ivy is the only rendering engine.
PR Close#47346
We currently use all the ESM2020 and type sources as inputs for rollup
and type bundle actions, respectively. This is a source of slowness in
Bazel sandboxed builds because many unused files will be linked/made
available for many concurrently-running actions.
We should limit the inputs only to what is assumed to be used. We cannot
know exactly and need to include transitive types from `node_modules`,
but that is an inevitable construct with the current Bazel rules.
Note that the external node modules could still bring in a lot of files,
like in Material where the `.d.ts` files for all locales are brought
into the sandbox (from `@angular/common`). We likely would need to
remove these files in a postinstall for now, to speed up actions,
similar to how we did it for RxJS in all repositories. These are known
to be not used in the components repo.
PR Close#46187
Joey Perrott