You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
One owner file reached through both the shared-dep and direct-style paths gets two HMR events per class #453
Split out of a Codex review finding on #452. Pre-existing on main — measured identical before and after that PR.
Symptom
One component .ts file reaches a changed style through both dispatch paths: one of its components uses a style that @uses the shared partial, another uses the partial directly as a styleUrl. Editing the partial emits twoangular:component-update events per class.
Measured (one file, TransitiveComponent via probe-a.scss → @use './probe-shared', DirectComponent via _probe-shared.scss directly):
handleHotUpdate dispatches the shared-dep loop first, then the direct-resource block. The guard between them is:
if(!(handled&&!isDirectStyle))// skips only a transitive-ONLY partial
When the file is also a direct styleUrl, the guard passes even though handled is already true, so the direct loop dispatches an owner the shared-dep loop just dispatched. That is deliberate — the test at test/style-deps-hmr.test.ts:338 depends on the direct branch running after handled is set — but it uses two different owner files, so the single-owner duplicate is uncovered.
Impact is low
The second event is normally a no-op. The endpoint consumes the pending slot on the first fetch (index.ts:632, :730), so the second fetch returns an empty module and the client's m.default && ɵɵreplaceMetadata(...) short-circuits (initializer.rs:74-85). No second metadata replacement, no view recreation.
One real edge remains: has() and delete() are separated by an await readFile plus the compile, so two concurrent requests can both pass the check and both serve real content, producing two ɵɵreplaceMetadata calls.
Suggested fix
Hoist the per-update dispatchedOwners set introduced in #452 above the styleDepOwners loop and route both the transitive and the direct dispatches through it. Check first that style-deps-hmr.test.ts:338 semantics still hold — that test asserts both owners update, which dedupe by owner file preserves, but it should be confirmed rather than assumed.
Activity
fix(vite): do not re-dispatch a template owner covered by the shared-…
fix(vite): dispatch HMR for both decorator roles of one resource (#452)
fix(vite): send one HMR event per owner file, whatever the reach path (…