Fix: layout-transition false positives on JSX quoted transition values (#548) - #554
Conversation
#548) The value-capture regex stopped only at ;{}, so in single-line JSX style objects it ran past the closing quote and swallowed later properties, flagging layout props that were never transitioned. The capture now stops at the matching closing quote when the value is a quoted string, falling back to the old bounds for real CSS. Prepared with AI assistance under maintainer direction. Co-authored-by: Cursor <cursoragent@cursor.com>
Greptile SummaryThis change updates the regex detector so quoted JSX values for Confidence Score: 5/5Safe to merge based on focused execution of the affected detector behavior and the repository motion tests. The executed checks reproduced the previous false positives, confirmed they are corrected without losing intended width-transition detection, and passed all focused motion tests. Files Needing Attention: No additional attention is needed;
What T-Rex did
Reviews (1): Last reviewed commit: "Fix: layout-transition false positives o..." | Re-trigger Greptile |
The layout-transition matchers in the regex engine captured transition values with
[^;{}]+, which doesn't stop at a closing quote — so single-line JSX style objects likestyle={{ transition: 'border-color 200ms ease', height: '100%' }}falsely flaggedheight. The capture is now quote-aware, with the old bounds kept as fallback for real CSS. Fixes #548.Validation: 4 new regression tests in
tests/detect-antipatterns.test.js, fullbun run testgreen, both repro cases from the issue verified clean via the CLI while genuine quotedwidthtransitions still flag. No generated output touched (detect-text.mjsis not in the browser bundle).Prepared with AI assistance under maintainer direction.
Made with Cursor