fix(hmr): split component ids on the last @

[ashley-hunter]

Fixes HMR for components whose file path contains @, such as scoped packages compiled from source (node_modules/@scope/...) or monorepo directories like packages/@company/app/....

The bug

A component id is {path}@{ClassName}, and the class name was read back out as the text after the first @. When the path itself contains @, that produced an update function named after the path:

compileForHmrSync('<div></div>', 'Foo', 'node_modules/@scope/pkg/src/a.ts', null, {}).hmrModule
// export default function scope/pkg/src/a.ts_UpdateMetadata(scope/pkg/src/a.ts, ɵɵnamespaces) {

which is a syntax error. The vite plugin had the same bug in two places (the @ng/component endpoint and the per-file class-name registration). There it showed up as an empty HMR response every time, with no error.

The fix

A class name is a JS identifier and cannot contain @, so the last @ is the separator.

• generate_hmr_update_module_from_js: rsplit_once('@'), keeping the Component fallback when there is no @.
• compileForHmrSync: uses the class name it is already given instead of re-parsing the id. This matches Angular, which names the function from meta.className and never parses ids (@angular/build looks update modules up by the whole id).
• vite plugin: indexOf('@') → lastIndexOf('@') at both sites.

parseComponentId already used rfind.

Also: the endpoint served nothing on Windows

While fixing the CI run on Windows this turned up a separate bug in the same endpoint. componentsByFile and componentMetadataCache are keyed by the transform id, which Vite gives with forward slashes on every platform (C:/Users/...). The endpoint looked them up by path.resolve(fileId), which on Windows is a backslash path, so it:

• returned an empty module for every component, so template HMR did nothing, and
• never treated an empty style list as definitive.

The existing tests passed join() paths (backslashes on Windows), which match path.resolve, so they never saw it. The endpoint now looks the maps up by fileId verbatim and keeps resolvedId for the disk reads only. A new test sends a forward-slash id; it failed on Windows CI before the fix (113f612) with only that test red.

Tests

Each test was seen failing before its fix:

• Rust: ids with one and two @ in the path, and the no-@ fallback.
• compileForHmrSync / generateHmrModule / parseComponentId with scoped paths; the generated module is checked to parse.
• Plugin: the endpoint serves the module for a component under packages/@company/..., and pruning a removed class under an @ path leaves its sibling's pending update intact.
• transformAngularFile with hmr: true on a scoped path emits a parseable initializer containing the full encoded id.