Closes #456. Two commits: the functional swap, then the deletion it enables.

The problem

The @ng/component HMR endpoint read a class's own templateUrl / template / styleUrl(s) / styles by scanning decorator TEXT. The Rust extractor folds same-file constants and interpolates template literals; the text scan cannot. Every shape it could not read fell back to the FILE-LEVEL union, which in a multi-component file served a class its siblings' template and stylesheets.

const DIR = './themes'
@Component({ styleUrls: [`${DIR}/a.css`, SHARED_STYLE] })

Five review rounds on #455 each patched one syntactic form and revealed the next. This removes the text locators from the resolution path instead of teaching them to fold constants.

Two things the issue got wrong, both found by measurement

1. The metadata was not reachable. The issue assumed extract_component_metadata_sync was available. It is fully written and correct but carries no #[napi], so it was not on the JS surface at all. Adding the attribute is the entire Rust change.

2. There is nothing to cache. The issue suggested the data might already be in hand at transform time. It is not: result.styleUpdates is always empty and templateUpdates' values are discarded, only the keys kept. And a probe showed transform does NOT re-run before the endpoint serves an inline edit — transformCalls stays at 1 — so a transform-time cache would have served stale resources.

That turned out not to matter. The endpoint already does this per request:

:655   readFile(resolvedId)              fresh from disk, every request
:656   extractComponentUrls(source)      file-level union, every request   <- swapped

So this is a one-for-one swap of one call for another. No cache, no staleness, no ordering hazard. ~0.016 ms of Rust against the ~0.30 ms async hop it paid before.

Why the per-class answer is definitive

transform.rs:2557 and the extractor both call extract_component_metadata with the same collect_string_consts table. The transform's only extra step, resolve_styles (transform.rs:4061), turns URLs into content and never re-derives the URL list:

compiled styles = metadata.styles ++ concat(content(u) for u in style_urls)
                  |__ inline, first __|

Eight fixtures were compared against the real compile. All matched — including the one that looks like a partial read:

styleUrls: [OK_CONST, IMPORTED, './lit.css']
  metadata  ["./ok.css", "./lit.css"]
  compiled   OK_CSS, LIT_CSS

Two of three in both. The dropped import genuinely is not a stylesheet this component gets, so serving two is exact, not partial. The same held for spreads, let bindings, concatenation, and cross-file imports.

A class MISSING from the metadata is equally definitive. decorator.rs:90's ? drops a whole class when one key will not resolve — and measured, the real compile skips it too: decorator left intact, no ɵfac, no ɵcmp, its stylesheet not even in dependencies. Same for import { Component as Cmp }, a class nested below top level, and a @Directive.

So both fallbacks are deleted rather than narrowed.

What this retires, and what it does not

The unreadable state existed only because the text scan disagreed with Rust. With Rust as the source, that disagreement cannot occur.

What does NOT change is readStyles, its complete flag, and the three-valued styles argument from #457/#461. Those guard a RESOLVED file that cannot be READ — a filesystem question, still real, and still the thing that stops a truncate window during an atomic write from wiping live CSS. That code is byte-identical.

Three assertions flipped, deliberately

Three tests used styles: SOME_ARRAY_CONST and asserted no styles: key, on the stated theory that "the Rust extractor folded the CSS out of the constant". It does not. OXC's collect_string_consts folds STRING-valued consts; extract_string_value never walks an array. Verified against compiler output rather than reasoned:

const ARR = ['.FROM_ARRAY_CONST{...}']
@Component({ styles: ARR })        -> ɵcmp has NO styles property at all
@Component({ styles: ['.LIT{}'] }) -> styles:[".LIT[_ngcontent-%COMP%]{}"]

That component compiles with no styles, so styles: [] clears nothing that ever existed. All the #457/#461 read-failure guards are untouched and green.

Commit 2: the deletion was far smaller than expected

I predicted ~139 tests would delete and roughly half the scanner would go. Wrong, in the safe direction — nine of ten candidate helpers turned out to be live, all reachable from locateStylesInArgs / locateTemplateInArgs through findFieldInArgs. Only hasInterpolation was genuinely dead.

Of 206 tests: 22 unchanged, 78 keep their title with the call swapped to a surviving locator, 26 renamed because the old title named a concept that is gone, 76 deleted. Comment handling, decoy tokens and Unicode identifiers were all salvaged — the strip path still parses decorator text and still has to get them right.

Also deleted: inlineTemplateCache and inlineStylesCache, written and pruned and refreshed on hot update, and read by nothing — true before this PR.

stripComponentMetadata and its closure are untouched. It decides full reload versus hot update.

Verification

The six new tests are the const-folded cases the text scan could never read, each with a styled sibling in the same file to prove the contamination is gone. All six fail on ab79282; red-checked by restoring the old plugin file. One of them pins the invariant the whole design rests on: it runs the plugin's own transform, slices the emitted ɵcmp, and asserts the endpoint serves exactly what the compiler put there. If extractor and compiler ever diverge, that test moves.

Commit 2's behaviour is proven beyond e2e: stripComponentMetadata was run against both the old and new scanner over 744 generated sources — 62 decorator shapes by 12 file wrappers, including phantom decorators in comments and strings, CRLF, Unicode class names, malformed escapes, spreads and elisions. Zero differences.

Notes for the reviewer

• OXC and ngtsc genuinely differ on styles: CONST_ARRAY. ngtsc's partial evaluator would fold it; OXC does not. The endpoint is now exactly faithful to OXC, which is the right invariant — the browser runs OXC-compiled code. Making OXC match ngtsc is a separate extractor change, and those three tests would move again.
• styleUrl plus styleUrls together is order-dependent (decorator.rs:115 assigns for the array form and pushes for the scalar). The compile reproduces it exactly, so it is faithful and out of scope here.
• e2e/compare/src/discovery/finder.ts:93 carries a TODO waiting for exactly this binding, and hand-rolls a TypeScript-based extractor as a fallback. Untouched — a separate follow-up.
• findFieldInArgs's shorthandMeans parameter is now never passed a non-default value, making one branch unreachable. Left in place, since it is still referenced from a live function.