This was disabled a while ago, seemingly for some of the type worker
bundling issues. Those should be resolved as we improved/changed how we
bundle `.d.ts` anyway.

(cherry picked from commit 5083cbd)

This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.

Sets up `rules_js` and links dependencies into the bazel-bin.

This commit sets up `rules_ts`, providing the `ts_library` equivalent
for the `rules_js` migration.

The `ts_project` interop rule that we've built was also used in the
Angular CLI migration, and it allows us to mix `ts_project` and
`ts_library` targets; enabling an incremental migration.

This is an initial commit to migrate some `testing/` targets to
`ts_project`, leveraging the interop rule we've built.

Notably we also turn of strict deps checking temporarily as the deps
checking is only applicable when there are no interop deps anymore!

* Moves the public API goldens to `goldens/`
* Switches us to the `npm_package` variant of the golden testing rule.
  This variant is more future proof and will work well with the
  `rules_js` migration (as it takes arbitrary Bazel tree artifacts)

This will automatically result in Renovate updating the Aspect lock
files.

This will result in the release tool automatically updating the Aspect
lock files when necessary.

For linking of Angular packages we are using something more clever than
what we are doing with `rules_nodejs`. Instead of maintaing complexity
where we pre-link FESM bundles and somehow inject them into other Bazel
bundling steps (with complex linker mappings), we pre-link as part of
individual package postinstall steps, exposing the linked bundles via a
NodeJS exports condition.

This is possible vis this package/script:
https://github.com/devversion/angular-linking

Clearly this is not at a good location, but it's necessary right now to
ship this code via npm because `rules_js` struggles to use pnpm
extensions onto workspace 1st-party packages. Long-term we can either
decide to keep it that way, move it into e.g. dev-infra repository, or
we can explore shipping pre-linked bundles via APF. TBD.

Migrates all `ts_library` targets in `tools/` to use the `rules_js`
`ts_project` rule.

Improves the `ts_project` interop to work with Esbuild bundling. Right
now we can end up with multiple copies of the same source file.

e.g. input might import from `@angular/cdk/testing` and end up with
the version of `rules_nodejs` linker, while other imports to the native
`ts_library` targets end up being mapped to their actual sources in the
`bazel-bin`, and not inside `node_modules`

Migrates more `ts_library` targets to `rules_js`

…0642)

Fixes an issue where the value of the input element referenced by a
TimepickerInput component inside a shadow DOM was getting formatted too
often due to `TimepickerInput._hasFocus()` assuming the component wasn't
in the shadow DOM.

Fixes #30641

Co-authored-by: Caleb Kish <j69674031@gmail.com>
(cherry picked from commit ee44255)

fixes component retaining old data in memory even when its not used causing memory usage to increase

fixes #30322

(cherry picked from commit 1b4cae7)

As of recently, we switched our imports from module imports to relative
imports, when inside the same package. This is expected for proper code
splitting, and also for our upcoming `rules_js` migration.

Unfortunately this highlights an issue with the Angular compiler. We
occasionally re-export other entry-point modules from one entry-point
module. This is likely done for convenience, but we should stop doing
that going forward (and likely will naturally resolve this over time
with standalone either way).

The problem is that the Angular compiler, especially with HMR enabled
(i.e. no tree-shaking of imports), will try to generate imports in the
user code to symbols that are indirectly re-exported. This worked before
because the Angular compiler leveraged the "best guessed module", based
on the "last module import" it saw before e.g. discovering the
re-exported `ScrollingModule`; hence it assumed all exports of that
module are available from `@angular/cdk/scrolling`. This assumption no
longer works because the last module import would be e.g. `cdk/overlay`,
which relatively imports from scrolling to re-export the module then.

There are a few options:

- teach the compiler about relative imports inside APF packages with
  secondary entry-points. Possible, but won't work for users with older
  compiler versions. Maybe a long-term good thing to do; on the other
  hand, standalone is the new future.

- switch back to module imports. Not possible and relative imports
  should work inside a package IMO.

- re-export the exposed symbols, under a private name. This is the
  easiest approach and there also aren't a lot of module re-exports; so
  this is a viable approach taken by this commit.

Inside Google, the latter approach is automatically emitted by the
compiler, when everything is built from source; but that's not usable
here; but confirms this approach as being reasonable. Ideally we will
stop re-exporting modules in APF packages, and long-term we start
supporting the proper module guessing with relative imports.

Fixes #30663.