…#58515)

The use of relative imports vs. module imports and the existing mismatch
can cause symbols to be duplicated in migrations. This is problematic as
it breaks migration logic or compiler logic in the worst case.

Long-term we will solve this by having a better Bazel toolchain where
both relative and module imports can point to the same files; but in
practice this is not the case right now.

This commit fixes the fallback template logic in the signal
input/queries migration; in case no type check block information is
available.

PR Close #58515

…module are discovered (#58515)

Currently when application source code references e.g. an NgModule that
points to references that aren't available, the compiler will break at
runtime without any actionable/reasonable error.

This could happen for example when a library is referenced in code, but
the library is simply not available in the `node_modules`. Clearly,
TypeScript would issue import diagnostics here, but the Angular compiler
shouldn't break fatally. This is useful for migrations which may run
against projects which aren't fully compilable. The compiler handles
this fine in all cases, except when processing `.d.ts` currently... and
the runtime exception invalides all other information of the program
etc.

This commit fixes this by degrading such unexpected cases for `.d.ts`
metadata reading to be handled gracefully. This matches existing logic
where the `.d.ts` doesn't necessarily match the "expecation"/"expected
format".

The worst case is that the Angular compiler will not have type
information for some directives of e.g. a library that just isn't
installed in local `node_modules`; compared to magical errors and
unexpected runtime behavior.

PR Close #58515

…58515)

This is useful for some migrations and eases debugging, so we are
building an environment-guarded debug print.

PR Close #58515

…module are discovered (#58515)

Currently when application source code references e.g. an NgModule that
points to references that aren't available, the compiler will break at
runtime without any actionable/reasonable error.

This could happen for example when a library is referenced in code, but
the library is simply not available in the `node_modules`. Clearly,
TypeScript would issue import diagnostics here, but the Angular compiler
shouldn't break fatally. This is useful for migrations which may run
against projects which aren't fully compilable. The compiler handles
this fine in all cases, except when processing `.d.ts` currently... and
the runtime exception invalides all other information of the program
etc.

This commit fixes this by degrading such unexpected cases for `.d.ts`
metadata reading to be handled gracefully. This matches existing logic
where the `.d.ts` doesn't necessarily match the "expecation"/"expected
format".

The worst case is that the Angular compiler will not have type
information for some directives of e.g. a library that just isn't
installed in local `node_modules`; compared to magical errors and
unexpected runtime behavior.

PR Close #58515

…58515)

This is useful for some migrations and eases debugging, so we are
building an environment-guarded debug print.

PR Close #58515