Fix drop-shadow ignoring its opacity modifier when no size is specified - #20445
Fix drop-shadow ignoring its opacity modifier when no size is specified#20445koreahghg wants to merge 2 commits into
drop-shadow ignoring its opacity modifier when no size is specified#20445Conversation
…fied The bare `drop-shadow` utility (no size keyword, e.g. `drop-shadow/50`) computed the alpha-adjusted shadow into `--tw-drop-shadow-size` but never wired it into `--tw-drop-shadow`, the variable actually consumed by `filter`. It always fell back to the theme's default alpha instead. Named sizes (`drop-shadow-lg/50`) already handled this correctly by branching on whether a modifier alpha was present; apply the same branch to the bare utility.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. WalkthroughUpdated named Merge Risk: ⚪ Minimal · up to This change makes opacity modifiers work correctly for size-less drop-shadow utilities without altering other shadow behavior; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Confidence Score: 5/5The PR appears safe to merge with no actionable correctness, security, or quality issues identified. The changed branch correctly activates the already-computed alpha-adjusted drop-shadow value and follows the established implementation used for named drop-shadow sizes. Reviews (1): Last reviewed commit: "Add changelog entry for drop-shadow opac..." | Re-trigger Greptile |
Summary
The bare
drop-shadowutility (no size keyword, e.g.drop-shadow/50) ignored its opacity modifier and always rendered with the theme's default alpha instead.In
createUtilities'sdrop-shadowhandler (packages/tailwindcss/src/utilities.ts), the!candidate.valuebranch (baredrop-shadow) correctly computed the alpha-adjusted shadow into--tw-drop-shadow-size, but then unconditionally overwrote--tw-drop-shadow— the variable actually referenced byfilter: var(--tw-drop-shadow, )— with the raw, unmodified theme value, discarding the alpha entirely.Every sibling branch (arbitrary value/color, and the named-size branch, e.g.
drop-shadow-lg/50) already handles this correctly by branching on whether a modifier alpha is present and pointing--tw-drop-shadowatvar(--tw-drop-shadow-size)in that case. This PR applies the same branch to the baredrop-shadowutility.Before:
After:
Test plan
filtertest inpackages/tailwindcss/src/utilities.test.tsalready exercisesdrop-shadow/25anddrop-shadow/12.5; its inline snapshot previously asserted the buggy (unmodified-alpha) output. Updated the snapshot to reflect the corrected behavior vianpx vitest run packages/tailwindcss/src/utilities.test.ts -t "^filter$" -u, and confirmed the diff only changes--tw-drop-shadow: drop-shadow(var(--drop-shadow))→--tw-drop-shadow: var(--tw-drop-shadow-size)for the two alpha-modified cases.npx vitest run packages/tailwindcss/src/utilities.test.ts— all 398 tests pass.npx vitest run packages/tailwindcss/src/intellisense.test.ts packages/tailwindcss/src/index.test.ts— all 277 tests pass (no regressions in related suites).npx prettier --check packages/tailwindcss/src/utilities.ts packages/tailwindcss/src/utilities.test.ts— passes.npx tsc --noEmit— no new type errors introduced by this change.