Paul Gschwendtner

Agreed 👍 I've replied on the toolchain start PR you created. > Using some JS-based devserver sounds great, but that certainly wouldn't go in rules_nodejs to begin with, so I...

@gregmagolan Thanks for the investigation. So based on that, to me it sounds like the registry prefixes are currently just throwing off the logic, but in practice- with both variants...

FYI that team members often run into issues, even with the workaround, because `pnpm import` seems to behave different when running under `yarn bazel`. The registry prefixes are always added...

@pmvald I've added Alex as a reviewer as well. Can you explain more in the commit message what we are doing so that we have it captured in history? At...

Is there a reason for this? (the commit message doesn't capture). IIRC the misc folder was relevant for easier distinction of @angular/ prefixed packages vs non-prefixed ones

SGTM. Thx. One contrast in terms of build process: It does seem easier if all packages under `packages/` are `@angular` prefixed, as this allows e.g. the `module_name` Starlark macros to...

FYI: This seems to break some internal targets: ``` Error: Unexpected expression for signal input write type. at template_symbol_builder_unwrapSignalInputWriteTAccessor at SymbolBuilder.getSymbolOfInputBinding ```

@cexbrayat I won't have time currently, but can help providing as much details as possible. My guess is that the symbol retrieval is triggered on some unexpected AST node. Will...

@cexbrayat The template looks pretty simple and fine. All inputs are targeting signal inputs— so that's good. At least the error is somewhat "reasonable". Can you print what type of...

@cexbrayat Thanks. Hmm. This didn't help a lot: `actual SyntaxKind Identifier`. It sounds like some input in the type check block code is directly accessed. in form of. e.g. `x[ɵINPUT_SIGNAL_BRAND_WRITE_TYPE]`,...