Find a scoped <style> regardless of what precedes it

[tylerturdenpants]

Fixes #423.

The bug

The Template visitor picked the block to extract by tag alone:

let styleTag = node.body.find(
  (n) => n.type === 'ElementNode' && n.tag === 'style',
);

if (hasScopedAttribute(styleTag)) {

while the ElementNode visitor removes every scoped style element. Those two disagree, and the disagreement loses CSS: a global <style> earlier in the template makes find return the wrong element, hasScopedAttribute false, and the entire extraction branch is skipped — but the scoped tag is still deleted from the compiled template. The CSS is emitted nowhere, and no error or warning is produced.

addInfo() never runs either, so the classes are never collected. Even if the stylesheet had been emitted, the elements keep their unpostfixed class names and nothing would have matched.

<template>
  <style>
    .global { color: red; }
  </style>

  <style scoped>
    .scoped { color: blue; }  {{! silently dropped }}
  </style>
</template>

Reversing the two blocks makes it work.

The fix

Select by the scoped attribute rather than the tag, which is the fix suggested in the issue. That closes the ordering case.

It does not close the second symptom the issue mentions in passing: a template with two <style scoped> blocks loses the second one the same way, because only the first is ever extracted and the rest are removed regardless. I confirmed the one-line fix alone leaves that case broken.

Supporting several blocks per template is a larger design question. Rather than answer it quietly, this refuses the second block with an explicit error, since emitting the first and silently discarding the second is the one behaviour nobody wants:

Only one <style scoped> is supported per template, but 2 were found. Merge them into one.

Happy to change that to "merge them and emit both" if that is preferred — it is a small change from here, and the tests say which behaviour is intended either way.

Tests

Two in template-plugin.test.ts, using the file's existing transform / virtualImportUrlsOf / templateContentsOf helpers. Both fail against the plugin as it stands on main: the first emits no import and leaves the class unpostfixed, the second resolves instead of throwing.

The first snapshots the compiled template and the emitted virtual import. That also pins the other side of the fix, since the snapshot shows a genuinely global <style> still shipping as written rather than being extracted or removed.

The second stays a toThrow rather than a snapshot: babel prefixes the message with an absolute filename, so a snapshot of it would only pass on the machine that wrote it.

Full suite: 205 passed (was 203), no regressions.

Relationship to #422

#422 adds a stylelint customSyntax that lints every root-level <style scoped>, which is how this was found: the linter reports problems in CSS the build discards. #422 documents that divergence as a known limitation and links here; it does not fix it.

The two are independent and can land in either order. I verified this branch's tests and fix pass against #422's code as well as against main — the fix touches only the Template visitor body, while #422 touches the imports and moves the attribute helpers into a shared style-tag.js, so they occupy different regions.

Whichever lands second: #422's "Known limitations" bullet about the build dropping scoped CSS becomes false once this merges, and its link to #423 becomes a dangling reference to a closed issue. That bullet should be removed.

[NullVoxPopuli]

this test would be better as an inline snapshot. the individual expects lose context / "the plot", as claude often does

[NullVoxPopuli]

(I think all the new tests, actually)

[tylerturdenpants]

Both new tests now assert with snapshots, in 8449956.

The template snapshot carries the whole story on its own -- scoped class postfixed, global block shipped as written, scoped tag removed:

[
  "<div class="scoped_e65d154a1">hi</div>
<style>
  .global { color: red; }
</style>",
]

plus the emitted virtual import, same shape as the lang="scss" tests above.

That made the third test ("leaves a preceding global <style>") a strict subset of this one, so I dropped it rather than keep a near-duplicate. Say the word if you would rather keep it separate.

The second-block case stayed a toThrow, matching babel-plugin.test.ts:99. Babel prefixes the message with the absolute filename, so toThrowErrorMatchingInlineSnapshot writes my home directory into the snapshot and only passes on this machine.

Both still fail against the pre-fix plugin -- I checked by swapping in the version from main.

[tylerturdenpants]

Went back over the whole review. The four comment deletions were one note, not four, and I had only applied it to the tests -- template-plugin.js still carried the same kind of prose I had added above the filter and the length check. Both gone in cee6d1a, leaving the one-line comment that was there before this branch. The error message covers what the second one was saying.

The diff against main for that file is now just the behaviour change.