[ym256-stanford]

Summary

Adds regression coverage for the <template>-fragment reproduction case from #4383. The defect itself — invalid_composition_variables_declaration only validating data-composition-variables on <html> — was already fixed by #4454 (571c99c), which now validates every element carrying the attribute. The fix landed without referencing the issue, so it stayed open; this PR closes the loop with the missing test.

Evidence

Ran the issue's reproduction script verbatim against main (deeb8d4):

html [ "invalid_composition_variables_declaration" ]
root [ "invalid_composition_variables_declaration" ]
template [ "invalid_composition_variables_declaration" ]

All three malformed declarations are now diagnosed, matching the issue's expected output. The existing root case was covered by a test added in #4454; the template-fragment case (<template> + isSubComposition: true) was not — this PR adds it.

Validation

• bun run --cwd packages/lint test src/rules/composition.test.ts — 202/202 pass
• bunx oxlint / bunx oxfmt --check on the changed file — clean

Closes #4383

[miguel-heygen]

Thanks for tracking this one down and closing the loop. I confirmed the claim against main: the rule validates every element carrying the attribute, not just the root element, so the defect is already fixed and a test is the right remaining piece. The new case takes the same code path as the existing root element test, so it is close to redundant, but it pins the exact reproduction from the issue and that is worth keeping.

CI has not run on this head yet, only the mergeability and WIP checks, so a maintainer will need to approve the workflow run before this merges.

[jrusso1020]

Approving at 004afd60, adding to Miguel's approval at the same head.

I checked the premise: #4454 (571c99ce9, on main) made the rule validate every element that carries data-composition-variables, so the bug in #4383 is already fixed and a test is the right remaining piece. I applied this test onto current main and the composition suite passes 202 of 202. Like Miguel said, it takes the same path as the existing root-element case, but it pins the exact reproduction from the issue, which is worth having before Closes #4383 fires.

One thing will block the merge: GitHub reports the commit as unsigned, and main requires signed commits. Re-signing it (for example git commit --amend --no-edit -S and a force push) and adding the key to GitHub as a signing key will clear that.

Need: yes, it closes the loop on #4383 · Size: ok · Reuse: extends the existing describe block · Simpler: already minimal

— Rames

[jrusso1020]

Thanks, @ym256-stanford. This one is approved, and it'll go into the merge queue once these are sorted:

• Signed commits: 1 commit(s) on this branch aren't verified, and main requires signed commits. GitHub's guide: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

Once it's green and signed, we'll queue it at your new head. If you push code changes beyond a rebase, we'll take another look first.

— Rames

[jrusso1020]

This is approved, but main requires signed commits. Could you re-sign (git rebase main --exec 'git commit --amend --no-edit -S') and force-push? We'll re-approve right after.

[ym256-stanford]

@jrusso1020 Thanks for the review! I’ve re-signed and pushed the commit, and GitHub now shows it as verified. The PR remains approved and has no merge conflicts, but the workflows are awaiting maintainer approval. Could you approve the CI runs and, once the required checks pass, add it to the merge queue? Happy to address anything CI finds.