fix(styled-components): strip line comments after multiline declarations

[kdy1]

Summary

• Fix styled-components CSS minification so // comments after multiline declarations are stripped when the line starts with closing parens.
• Preserve the existing URL, string, and still-open-paren guards for inline // handling.
• Add issue styled-components: Line comments are not supported in multiline style declarations #615 regression coverage for the Rust fixture suite and WASM snapshot.

Fixes #615.

Validation

• cargo test -p styled_components --lib
• cargo test -p styled_components --test fixture issue_615 -- --include-ignored
• pnpm exec vitest run --testTimeout=0
• cargo fmt -p styled_components --check

[changeset-bot]

⚠️ No Changeset found

Latest commit: e736a9d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[claude]

Code Review

Reviewed the change in packages/styled-components/transform/src/visitors/minify/css.rs and the accompanying test fixtures.

Correctness

The fix is sound. strip_line_comment operates on a single line (after minify splits by line breaks), so the previous == check broke for any line that contains a closing paren without a matching opening paren — exactly the case when a multiline declaration like calc(...) is wrapped across lines and the trailing // comment ends up on the same line as the lone );. Trace on ); // comment:

• subs = [" ); ", " comment"]
• predicate(" ); "): count('(') == 0, count(')') == 1 → old 0 == 1 is false (keep joining, comment is preserved), new 0 <= 1 is true (break, comment stripped). ✅

The symmetric case is preserved: a line with a still-open ( (e.g. foo( // bar) still has count('(') > count(')'), so the predicate stays false and the // is correctly retained as part of the (still-open) parenthesized content.

Possible side-effect to flag

The relaxation is asymmetric: lines with more ) than ( will now eagerly treat // as a comment. Two scenarios worth noting:

1. Closing parens inside quoted CSS strings (e.g. content: "foo)"; // comment) — count(')') will count the in-string ), but since the new check only requires <=, this is harmless and arguably more correct than before (the // is genuinely a comment there).
2. Genuinely unbalanced CSS (e.g. () ) // comment) — old code preserved the //, new code strips it. CSS-in-JS is unlikely to produce this and stripping is the safer default, but it is a small behavior change worth being aware of.

This also intentionally diverges from the upstream babel-plugin-styled-components (s.split('(').length === s.split(')').length). A short comment on line 68 noting the divergence and pointing at issue #615 would help the next maintainer trying to keep parity with babel.

Test coverage

• Unit test in test_strip_line_comment directly exercises the regressed predicate — good.
• Fixture issue-615 reproduces the original failure end-to-end and the WASM snapshot picks it up automatically via walkDir.
• Minor nit: the expected output preserves trailing whitespace (" ); "). That's an accurate reflection of reduce_substr's semantics (it stops short of joining //comment back), but a one-line comment would prevent a future contributor from "cleaning up" what looks like a stray trailing space.
• The PR description mentions --include-ignored for the fixture test, but issue-615 isn't marked #[ignore]. Harmless, just slightly misleading.

Other notes

• No performance concern: same number of split/count operations.
• No security concern.
• Diff is appropriately minimal — surgical operator change with targeted regression tests.

Overall: clean fix with appropriate coverage. Optional improvements: an inline comment explaining the <= (vs ==) choice and the divergence from upstream.