In some applications, developers define a `ts_library` that just consists of `d.ts` files (e.g. to type `module.id`; see: https://github.com/angular/material2/blob/master/src/module-typings.d.ts), and expect the `esm5.bzl` file to not throw an error like:
```
target.typescript.replay_params.outputs
struct' object has no attribute 'outputs'
```
The "replay_parameters" property will exist in that case, but is set to "None" because there is no action that should be replayed in favor of producing ES5 outputs. See: https://github.com/bazelbuild/rules_typescript/pull/326. Notice that this right now breaks similarly because an empty `struct()` is returned that does not have a property called `outputs`. [#326](https://github.com/bazelbuild/rules_typescript/pull/326) fixes that by being explicit that there is no _action_ at all.
PR Close#27401
* Currently when building a `ng_module` with Bazel and having the flat module id option set, the flat module files are not being generated because `@angular/compiler-cli` does not properly determine the entry-point file.
Note that this logic is not necessarily specific to Bazel and the same problem can happen without Bazel if multiple TypeScript input files are specified while the `flatModuleIndex` option has been enabled.
PR Close#27200
Currently when building the `ng_package` multiple times, the old `ng_package` output will be copied over to the new `ng_package` content. Resulting in packages like `src/cdk/npm_package/npm_package/npm_package/AND_MORE`.
This happens because currently all TypeScript definition files are resolved from within the `binDir`. This is just wrong because it could then take up the `d.ts` files from the previous `ng_package` output. All typescript definitions that belong to the target package, should be resolved through Bazel and copied based on that computation.
Also fixes that `esm` files aren't written to the `ng_package` on Windows. This is because we try to flatten paths using the `path.delimiter` while the path is always using Posix delimiters (causing the paths to be incorrect)
PR Close#27200
* Currently when building the ES5 and ES2015 output, `ngc_wrapped` will fail because it tries to write the `fs.openSync` the tsickle output file at the same time. This causes a runtime exception in Windows and can be fixed by just writing the externs for ES5 mode to the proper ES5 "output root".
PR Close#27200
* Fixes that `ng_package` does not work generate UMD bundles on Windows because the `esm5/` files are not written to the output directory. This is because `rootDirs` and `rootDir` are posix paths and cause invalid relative paths when mixed with Windows backslash paths.
PR Close#27200
Also build releases into a dedicated output_base so you can't
accidentally publish with outdated version stamp.
Bump the version of rules_nodejs so we don't need to create the
symlink_prefixes for the .publish command to work.
PR Close#27362
BREAKING CHANGES:
Bazel users: rules_angular_dependencies() will no longer install transitive dependencies of build_bazel_rules_nodejs and build_bazel_rules_typescript. User WORKSPACE files will now need to install rules_nodejs and rules_typescript transitive deps directly:
```
load("@build_bazel_rules_typescript//:package.bzl", "rules_typescript_dependencies")
rules_typescript_dependencies()
load("@build_bazel_rules_nodejs//:package.bzl", "rules_nodejs_dependencies")
rules_nodejs_dependencies()
```
PR Close#27264
A recent commit (probably 2c7386c) has changed the import graph of the
DI types in core, and somehow results in the ngc compiler deciding to
re-export core DI types from application factories which tangentially
use inject(). This is not really surprising; ngc's import graph can be
very unstable.
However, this results in a re-export of InjectFlags surviving JS
compilation. InjectFlags was a const enum, akin to an interface in TS,
with no runtime repesentation. This causes a warning to be emitted by
Webpack when it sees the re-export of InjectFlags.
This commit avoids the issue by removing 'const' from the declaration
of InjectFlags, causing it to have a runtime value. This is a temporary
fix. The real fix will be for ngc to no longer write exports of const
enums.
Testing strategy: manually verified. Due to the problem only manifesting
when recompiling after a change and then running Webpack, there is no
existing framework via which this could be easily tested with an
integration test. Additionally, the potential for this issue is gone in
Ivy, so this solution is only temporarily needed.
Fixes#27251.
PR Close#27279
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
Some engineers were already on Yarn 0.10.x which was permitted by the range in our package.json#engines
However this introduced 'integrity sha512' lines into the yarn.lock files.
Then when engineers use yarn 0.9 (in particular, Bazel did this) then the lock files get tons of meaningless edits.
We could force everyone back to yarn 0.9 but this commit chooses to instead advance everyone past 0.10
PR Close#27193
Now that the Ivy switch transform uses ts.getMutableClone() to copy
statements, there's no need to set .parent pointers on the resulting
updated nodes. Doing this was causing assertion failures deep in
TypeScript in some cases.
PR Close#27170
Currently the `useJit` option from `TestBed.configureCompiler` isn't supported. These changes rework the existing test suites not to pass in `useJit` when running with Ivy.
PR Close#27067
This option means guards and resolvers will ignore changes to optional
parameters such as query and matrix params. When the path or any path
params change, guards and resolvers will be run
Related to discussion in #18253
FW-560 #resolve
PR Close#26861
