fix: remove unecessary important declarations#751
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThis pull request refactors CSS styling across multiple component modules and exports a TypeScript interface. The CSS changes focus on removing Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
Shreyag02
requested review from
paanSinghCoder and
rohanchkrabrty
and removed request for
rohanchkrabrty
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/raystack/components/calendar/calendar.module.css (1)
173-180: Doubled-class specificity hack works, but consider a comment.
.calendarPopover.calendarPopoverintentionally doubles specificity to(0,2,0)to override the base.popoverrule(0,1,0)frompopover.module.csswithout!important. This is a known trick, but unusual enough that a future reader may "simplify" it back to a single class and silently break the override. Consider adding a brief comment explaining the intent.Proposed refactor
+/* Doubled selector intentionally raises specificity to override base .popover styles without !important. */ .calendarPopover.calendarPopover { padding: var(--rs-space-3);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/raystack/components/calendar/calendar.module.css` around lines 173 - 180, The doubled-selector .calendarPopover.calendarPopover is intentionally used to raise specificity to override the base .popover rule from popover.module.css; add an inline comment above the .calendarPopover.calendarPopover rule explaining that the duplicated class is deliberate to achieve specificity (0,2,0) instead of using !important so future maintainers don't "simplify" it back to a single class and break the override.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/raystack/components/filter-chip/filter-chip.module.css`:
- Around line 153-157: The current selector
[class*="input-field-module_inputWrapper"] in filter-chip.module.css is fragile
because it depends on generated CSS-Module class names; instead, add a stable
class on the InputField wrapper (e.g., add a prop/classNames that applies
styles.nestedInputWrapper to the wrapper in the InputField component), then
replace the fragile selector in filter-chip.module.css with .nestedInputWrapper
and adjust usages accordingly; alternatively, import or compose the exported
inputWrapper from input-field.module.css into filter-chip.module.css or mark it
:global()—but prefer adding the explicit nestedInputWrapper class to InputField
and target that from filter-chip.module.css for a robust fix.
---
Nitpick comments:
In `@packages/raystack/components/calendar/calendar.module.css`:
- Around line 173-180: The doubled-selector .calendarPopover.calendarPopover is
intentionally used to raise specificity to override the base .popover rule from
popover.module.css; add an inline comment above the
.calendarPopover.calendarPopover rule explaining that the duplicated class is
deliberate to achieve specificity (0,2,0) instead of using !important so future
maintainers don't "simplify" it back to a single class and break the override.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6d3f52e7-8eeb-478a-980d-1a11c9d81f0f
📒 Files selected for processing (5)
packages/raystack/components/calendar/calendar.module.csspackages/raystack/components/code-block/code.module.csspackages/raystack/components/filter-chip/filter-chip.module.csspackages/raystack/components/search/search.module.csspackages/raystack/components/select/select-root.tsx
| .inputFieldWrapper [class*="input-field-module_inputWrapper"], | ||
| .dateFieldWrapper [class*="input-field-module_inputWrapper"] { | ||
| border: none; | ||
| background: none; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm the CSS-Modules localIdentName format used in the build, and whether any other files rely on the same hash-based pattern.
fd -t f -e js -e ts -e mjs -e cjs -e json | xargs rg -nP 'localIdentName|cssModules|modules\s*:' 2>/dev/null | head -50
echo '---'
rg -nP 'class\*?="[^"]*module_' --type=css | head -30Repository: raystack/apsara
Length of output: 500
🏁 Script executed:
# Find build configuration files to locate localIdentName setting
fd -t f \( -name "webpack.config.*" -o -name "vite.config.*" -o -name "next.config.*" -o -name "rollup.config.*" -o -name "tsconfig.*" -o -name "*.config.*" \) | head -20Repository: raystack/apsara
Length of output: 289
🏁 Script executed:
# Search for CSS modules configuration and localIdentName
rg -nP 'localIdentName|cssModuleFormat|ident.*Name' --type=js --type=ts --type=json 2>/dev/null | head -50Repository: raystack/apsara
Length of output: 41
🏁 Script executed:
# Locate the input-field.module.css file
fd -t f -name "*input-field*" | grep -E '\.(css|scss|less)$'Repository: raystack/apsara
Length of output: 289
🏁 Script executed:
# Check if the referenced class exists in input-field.module.css
if [ -f "packages/raystack/components/input-field/input-field.module.css" ]; then
echo "=== input-field.module.css content ===" && cat "packages/raystack/components/input-field/input-field.module.css"
else
echo "File not found at expected path, searching for it..."
fd -t f -name "input-field.module.css"
fiRepository: raystack/apsara
Length of output: 5146
🏁 Script executed:
# Search for other instances of this pattern targeting module_* classes
rg '\[class\*="[^"]*module_' --type=css -A 2 -B 2Repository: raystack/apsara
Length of output: 607
🏁 Script executed:
# Find and examine the filter-chip component code
fd -t f -name "filter-chip.tsx" -o -name "filter-chip.ts" -o -name "filter-chip.jsx" -o -name "filter-chip.js" | head -5Repository: raystack/apsara
Length of output: 289
🏁 Script executed:
# Also check for the component directory
fd -t d -name "filter-chip" | head -3Repository: raystack/apsara
Length of output: 289
🏁 Script executed:
# Look for imports of InputField in the filter-chip directory
fd -t f -path "*/filter-chip/*" \( -name "*.tsx" -o -name "*.ts" -o -name "*.jsx" -o -name "*.js" \) | head -10Repository: raystack/apsara
Length of output: 227
🏁 Script executed:
# Find filter-chip component files with correct syntax
find . -path "*/filter-chip/*" -type f \( -name "*.tsx" -o -name "*.ts" -o -name "*.jsx" -o -name "*.js" \) 2>/dev/nullRepository: raystack/apsara
Length of output: 432
🏁 Script executed:
# Check the actual filter-chip component directory
ls -la packages/raystack/components/filter-chip/ 2>/dev/null | head -20Repository: raystack/apsara
Length of output: 507
🏁 Script executed:
# Search for references to InputField within filter-chip directory
grep -r "InputField" packages/raystack/components/filter-chip/ 2>/dev/nullRepository: raystack/apsara
Length of output: 370
🏁 Script executed:
# Examine the filter-chip.tsx to see how InputField is used
cat -n packages/raystack/components/filter-chip/filter-chip.tsxRepository: raystack/apsara
Length of output: 7089
🏁 Script executed:
# Also examine the input-field component to see what class it generates for the wrapper
cat -n packages/raystack/components/input-field/input-field.tsx | head -100Repository: raystack/apsara
Length of output: 3493
Fragile CSS-Modules selector that relies on generated class-name pattern.
The selector [class*="input-field-module_inputWrapper"] at lines 153-157 depends on the CSS-Modules build generating class names with the specific pattern [filename]_[classname] (e.g., from the current input-field.module.css file). Upgrading the build tool, changing the localIdentName configuration, renaming the input-field module file, or enabling production minification will silently break this selector, causing the nested border/background overrides to stop applying.
Consider one of:
- Add an explicit, stable class to the
InputFieldwrapper via a prop (e.g.,classNames={{ wrapper: styles.nestedInputWrapper }}) and target that instead. - Export the inputWrapper class from
input-field.module.cssvia:global()or import/compose it in filter-chip.module.css. - At minimum, add a comment in both files documenting this coupling so a future file rename or build config change triggers an update here.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/raystack/components/filter-chip/filter-chip.module.css` around lines
153 - 157, The current selector [class*="input-field-module_inputWrapper"] in
filter-chip.module.css is fragile because it depends on generated CSS-Module
class names; instead, add a stable class on the InputField wrapper (e.g., add a
prop/classNames that applies styles.nestedInputWrapper to the wrapper in the
InputField component), then replace the fragile selector in
filter-chip.module.css with .nestedInputWrapper and adjust usages accordingly;
alternatively, import or compose the exported inputWrapper from
input-field.module.css into filter-chip.module.css or mark it :global()—but
prefer adding the explicit nestedInputWrapper class to InputField and target
that from filter-chip.module.css for a robust fix.
rohilsurana
changed the title
1 participant
Description
removed the unnecessary use of !important in css in reported components
Type of Change
How Has This Been Tested?
Dev testing
Checklist:
Related Issues
#678