Repository navigation
Per-class resource locators are text-based, so const-folded templateUrl/styleUrls fall back to file-level resolution #456
Description
Activity
A later review round on #455 suggested an alternative worth recording here, since it is a product decision rather than a bug fix.
When a per-class answer is unavailable — a const-form
styleUrls, a computed metadata key — #455 falls back to the file-level union. In a multi-component file that union contains the siblings' stylesheets, so the class receives its own CSS plus theirs. That is whatmaindoes today for every class, so it is not a regression, but it is knowingly contaminated.The suggestion: trigger a full reload instead of compiling a union we know is wrong.
The trade-off is real in both directions. A full reload is always correct but costs the dev-server experience on every const-form component, including single-component files where the union is harmless. The union keeps HMR fast and is only wrong when siblings exist. Resolving this issue as described — exposing per-class resolved resources from the Rust extractor — removes the choice entirely, which is why I would rather do that than pick a lesser evil now.
Recording it so the option is not lost if the redesign is deferred.
Also applies to inline
styles, not just the URL fields.const BASE = ".base{}"; styles: [BASE, ".local{}"]— Rust folds the const and compiles both stylesheets. The text scanner reads one literal, marks the field incomplete, and the endpoint omits thestyleskey, so edits to.local{}do not hot-apply.Verified against real
@angular/core22.1.3:rust styles = [".base{}", ".local{}"] before HMR def.styles = [".base[_ngcontent-%COMP%]{}", ".local[_ngcontent-%COMP%]{}"] after HMR def.styles = [".base[_ngcontent-%COMP%]{}", ".local[_ngcontent-%COMP%]{}"] (stale)Same root cause: the locators are text-based and cannot fold same-file constants. Resolving constants would fix all three fields at once.
- added a commit that references this issue
on Aug 25, 2026
Split out of a Codex review finding on #455. Pre-existing — applies equally to the template locator merged in #449.
Symptom
The
@ng/componentHMR endpoint resolves a class's owntemplateUrlandstyleUrl(s)by scanning the decorator text. The Rust extractor statically folds same-file constants and interpolated template literals; the text scan cannot.Neither entry yields a string literal, so the per-class answer is "unknown" and the endpoint falls back to the file-level
styleUrlsunion. In a single-component file that is harmless. In a multi-component file it reintroduces exactly the cross-class contamination #451 removed.Current behavior is deliberate, not accidental
#455 makes the fallback explicit and distinguishes three states:
The third row is the const case. Falling back is strictly better than serving empty — a component keeps working — but it is not per-class correct.
Scope
This is not style-specific.
extractTemplateUrlFor(from #449) has the same limitation, and falls back totemplateUrls[0].Suggested fix
Expose per-class resolved resources from the existing AST metadata extraction —
extract_component_metadata_syncalready returnstemplateUrl/styleUrlsper class with constants folded — and have the endpoint consult that instead of re-scanning source text. That removes the text locators from the resolution path entirely rather than teaching them to fold constants.Worth checking first how the endpoint would get that metadata cheaply: it currently calls
extractComponentUrlsper request, andcomponentMetadataCacheexists but stores stripped source, not parsed metadata.