Upgrade to tailwind v4 #65
Conversation
|
@phucbm is attempting to deploy a commit to the 9d8 Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughConsolidates Tailwind configuration into inline CSS in Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant NextRoute as /api/revalidate
participant NextRuntime as Next.js Revalidation
Client->>NextRoute: POST revalidate request
Note right of NextRoute: route.ts determines tags per contentType
NextRoute->>NextRuntime: revalidateTag(tag, "max")
alt success
NextRuntime-->>NextRoute: 200 OK
NextRoute-->>Client: 200 OK
else failure
NextRuntime-->>NextRoute: error
NextRoute-->>Client: 500 Error
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
package.json (1)
33-33: Replacetailwindcss-animatewith a v4-compatible alternative.
tailwindcss-animate@^1.0.7is a legacy plugin incompatible with Tailwind CSS v4. Use a v4-compatible replacement such astw-animate-css.@tailwindcss/typography@0.5.16is compatible with Tailwind CSS v4.
🧹 Nitpick comments (1)
package.json (1)
43-43: Consider removing autoprefixer dependency.Tailwind v4 includes Lightning CSS, which automatically handles vendor prefixes, nesting, and minification. The
autoprefixerpackage is likely redundant now and can be safely removed to reduce dependencies.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
app/globals.css(1 hunks)package.json(2 hunks)postcss.config.js(0 hunks)postcss.config.mjs(1 hunks)tailwind.config.ts(0 hunks)
💤 Files with no reviewable changes (2)
- postcss.config.js
- tailwind.config.ts
🔇 Additional comments (7)
package.json (1)
38-38: LGTM! Tailwind v4 dependencies correctly added.The addition of
@tailwindcss/postcssand the upgrade totailwindcss@^4.1.16are correct for the Tailwind v4 migration.Also applies to: 47-47
postcss.config.mjs (1)
1-6: LGTM! PostCSS configuration is correct for Tailwind v4.The configuration correctly uses the
@tailwindcss/postcssplugin with ES module format, which aligns with Tailwind v4's simplified setup.app/globals.css (5)
1-3: LGTM! Import and plugin declarations are correct for Tailwind v4.The
@import "tailwindcss"syntax correctly replaces the old@tailwind base/components/utilitiesdirectives, and plugins are properly loaded using the@plugindirective.
5-5: LGTM! Custom dark variant is correctly configured.The custom variant uses
&:is(.dark *)to target descendants of elements with the.darkclass, which is the correct pattern for class-based dark mode in Tailwind v4.
7-60: LGTM! Theme configuration is correctly structured for Tailwind v4.The
@theme inlineblock properly defines:
- Container settings with padding and max-width
- Border radius scale using calc()
- Color mappings that bridge custom CSS variables to Tailwind's color system (the
--color-*prefix is required for Tailwind to recognize them)- Accordion animations with Radix UI integration
This CSS-first configuration approach is the recommended pattern for Tailwind v4.
62-105: LGTM! Color definitions using OKLCH are correct for Tailwind v4.The color values use the OKLCH color space, which provides better perceptual uniformity and consistency across modern displays. Both light (
:root) and dark (.dark) mode color schemes are properly defined with appropriate semantic naming.Note: Tailwind v4 with OKLCH requires modern browsers (Chrome 111+, Safari 16.4+, Firefox 128+).
107-136: LGTM! Layer definitions are correctly structured.The base, prose, and utilities layers properly use
@applydirectives and standard CSS. The scrollbar-hiding utilities provide good cross-browser compatibility.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/globals.css (1)
19-37: Optional: Simplify color mappings by removing unnecessary aliasing.The color mappings (lines 19–37) create a two-layer indirection:
--color-*→ original--*CSS variables. Tailwind v4 can reference CSS variables directly in the theme, so this aliasing is unnecessary and adds complexity. However, this is not a breaking issue if the intent is to maintain backward compatibility or preserve naming conventions from prior versions.If simplification is desired, consider referencing the original variables directly in the theme rather than aliasing through
--color-*tokens.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
app/globals.css(1 hunks)package.json(1 hunks)
🔇 Additional comments (6)
app/globals.css (5)
62-105: Color system correctly uses OKLCH color space.The migration appropriately adopts OKLCH color space for all CSS variables, aligning with Tailwind v4's modern default palette. Grayscale system colors use zero chroma, while the destructive color maintains saturation for a red tone. This follows best practices per the library documentation.
1-2: Tailwind v4 imports correctly applied.The new single-import syntax
@import "tailwindcss"(line 1) correctly follows Tailwind v4's migration guide. The animation library import (line 2) integrates the third-party animation utilities.
107-115: Base styles correctly apply theme colors.The base layer (lines 107–115) appropriately applies the new CSS variable–based theme to all elements and the body. The default border color now uses the CSS variable, aligning with Tailwind v4's modern styling approach.
43-59: No action required—keyframes inside@theme inlineare valid Tailwind v4 syntax.Tailwind v4 supports defining @Keyframes inside @theme blocks, which enables tree-shaking of unused keyframes. The accordion keyframe animations at lines 43–59 follow this supported pattern and require no changes.
117-121: Confirm @apply behavior within custom @layer in Tailwind v4.Custom layer names are valid in Tailwind v4 and treated as ordinary CSS layers. However, the code uses
@apply(a Tailwind directive) inside the custom@layer prose-m-noneblock, which combines a Tailwind directive with a custom CSS layer. Custom named @layer blocks are not processed as Tailwind utilities/components—they're left as normal CSS, so the interaction between@applyand this custom layer may not work as intended.Manually verify that
@apply prose-headings:m-0resolves correctly and produces the expected CSS output within the customprose-m-nonelayer. If this causes issues, move the styling to a built-in layer (@layer utilitiesor@layer base) or use standard CSS syntax.package.json (1)
37-37:tw-animate-cssv1.4.0 is confirmed compatible with Tailwind CSS v4.tw-animate-css v1.4.0 is published as a Tailwind CSS v4.0–compatible package, so the migration is safe. Verify that your project's animation requirements are fully covered by
tw-animate-cssor native Tailwind utilities following the removal oftailwindcss-animate.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/globals.css (1)
117-121: Fix prose heading margin rule—element modifiers don't apply to universal selector.The
prose-headings:m-0element modifier in Tailwind v4 is valid, but only targets heading elements (h1–h6), not all elements. The current rule@layer prose-m-none { * { @apply prose-headings:m-0; } }won't work as intended because the universal selector doesn't match heading elements.To remove margins from prose headings, use a direct selector:
@layer prose-m-none { .prose-headings { @apply m-0; } }Alternatively, Tailwind v4 recommends the @Utility API for custom utilities instead of @layer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
app/globals.css(1 hunks)
🔇 Additional comments (4)
app/globals.css (4)
62-105: OKLCH color values structure is solid.The :root and .dark CSS variables follow a consistent pattern and properly invert colors for dark mode. OKLCH values align with the PR objective and Tailwind v4 conventions. No issues detected.
107-115: LGTM.Standard @layer base usage; properly applies theme tokens to * and body elements.
123-136: LGTM.Standard scrollbar-hiding utilities using cross-browser CSS; no issues.
2-2: Thetw-animate-csspackage is a legitimate npm package that provides Tailwind CSS v4.0–compatible animation utilities, and the import statement@import "tw-animate-css";is the correct usage pattern. No issues detected.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
app/globals.css (1)
7-55: Minor: Inconsistent spacing in CSS custom property declarations within@themeblock.Lines 9–55 use no space after the colon in property declarations (e.g.,
--radius-sm:calc(...)). While valid, this deviates from common CSS formatting conventions (which prefer--radius-sm: calc(...)). Consider adding spaces for consistency across all declarations in this block for improved readability.Example fix for lines 9–11:
- --radius-sm:calc(var(--radius) - 4px); - --radius-md:calc(var(--radius) - 2px); - --radius-lg:var(--radius); + --radius-sm: calc(var(--radius) - 4px); + --radius-md: calc(var(--radius) - 2px); + --radius-lg: var(--radius);Apply the same fix to all property declarations in lines 14–36.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
app/globals.css(1 hunks)
🔇 Additional comments (4)
app/globals.css (4)
38-54: Verify keyframes nested in@themeare properly recognized by Tailwind v4.The
@keyframes accordion-downandaccordion-upare nested inside the@themeblock (lines 38–54). While the previous review noted this is valid in v4, confirm during testing that these keyframes are emitted correctly in the compiled CSS and that animation utilities properly reference them. If keyframes are missing in the final CSS, they may need to be moved outside@themeto a separate@keyframesblock.
59-78: OKLCH color syntax is valid; verify color accuracy against design system.The OKLCH color values use correct syntax (e.g.,
oklch(100% 0 0)for lightness, chroma, and hue). All declarations follow the format properly. However, semantically verify that the chosen OKLCH values match your design system's intended colors, especially for high-chroma colors like--destructive:oklch(62.8% 0.257 29.23)(line 73) and its dark mode counterpart (line 95).Recommended: Test the rendered colors in a browser using the browser DevTools color picker to confirm they match your design specifications.
Also applies to: 81-100
102-110:@layer baseusing@applyis valid in Tailwind v4; confirm utilities are generated.The base layer applies Tailwind utilities via
@applydirectives (e.g.,@apply border-borderon line 104). This pattern is supported in Tailwind v4. Verify that the generated CSS includes these utilities (e.g.,border-borderclass) and that color references to--color-backgroundand other tokens resolve correctly in the output.
1-5: The@import "tw-animate-css"import is valid and Tailwind v4-compatible.tw-animate-css is a Tailwind CSS v4-compatible replacement, and the correct way to use it is to add
@import "tw-animate-css"to your CSS file. The package is correctly declared in package.json (v^1.4.0), and the syntax on line 2 ofapp/globals.cssis correct for Tailwind v4.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/globals.css (1)
90-94: Invalid@layername causes Tailwind compilation error.Line 90 uses
@layer prose-m-none, which is not a valid Tailwind layer. The@layerdirective only accepts three values:"base","components", or"utilities". This will cause a build error.Change line 90 to use a valid layer name:
- @layer prose-m-none { + @layer components { * { @apply prose-headings:m-0; } }Alternatively, if this rule should be in the base layer (applied globally), use:
- @layer prose-m-none { + @layer base { * { @apply prose-headings:m-0; } }Choose based on whether this rule is meant as a component or base style.
🧹 Nitpick comments (1)
app/globals.css (1)
7-33: Color mappings reference CSS variables defined later; verify hoisting works as expected.Lines 14–32 create theme aliases that reference base CSS variables (
--background,--foreground, etc.) defined in the:rootblock (lines 35–56). While CSS custom properties support hoisting, this unconventional ordering could cause confusion or issues if the:rootvalues are not loaded in time. Consider moving the:rootand.darkblocks (lines 35–78) before the@themeblock to make the dependency explicit and improve readability.Optionally reorganize to move
:rootand.darkdefinitions before@themefor clarity:@variant dark (&:is(.dark *)); + :root { + --radius: 0.5rem; + --background: oklch(100% 0 0); + ... + } + + .dark { + --background: oklch(9.26% 0 0); + ... + } + @theme inline { --radius-sm: calc(var(--radius) - 4px); ... --color-background: var(--background); ... } - - :root { ... } - .dark { ... }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
app/globals.css(1 hunks)
🔇 Additional comments (2)
app/globals.css (2)
96-109: Scrollbar utilities look good.The scrollbar-hiding utilities are comprehensive and correctly target all major browsers. Implementation is sound.
2-2: No action required—tw-animate-cssis a valid dependency.The import on line 2 is correct.
tw-animate-cssis properly listed inpackage.jsonas a dependency ("tw-animate-css": "^1.4.0"), and the import path is valid.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tsconfig.json (1)
35-37: Minor: Redundant explicit path in includes.Adding
"wp.config.ts"explicitly is redundant since it's already matched by the"**/*.ts"glob pattern on line 33. The new.next/dev/types/**/*.tsinclusion is good practice for Next.js type discovery, so that part is fine.Consider removing the redundant
"wp.config.ts"entry for clarity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
app/api/revalidate/route.ts(2 hunks)package.json(1 hunks)tsconfig.json(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-06-26T17:28:47.375Z
Learnt from: CR
Repo: 9d8dev/next-wp PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-06-26T17:28:47.375Z
Learning: Leverage Next.js cache tags in data-fetching functions to enable granular and efficient cache revalidation.
Applied to files:
app/api/revalidate/route.ts
📚 Learning: 2025-06-26T17:28:47.375Z
Learnt from: CR
Repo: 9d8dev/next-wp PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-06-26T17:28:47.375Z
Learning: Set up a revalidation system where a WordPress plugin sends webhooks to a Next.js endpoint, which validates the webhook secret and calls revalidateTag(), with a default cache duration (e.g., 1 hour).
Applied to files:
app/api/revalidate/route.ts
🔇 Additional comments (1)
app/api/revalidate/route.ts (1)
42-67: No issues found—revalidateTagcalls are correct.The second parameter
"max"is the properprofileparameter for Next.js 15'srevalidateTagAPI. It's recommended for stale-while-revalidate behavior and represents best practice, whereas omitting it is now deprecated. The code correctly implements cache revalidation for the webhook integration.
| "resolveJsonModule": true, | ||
| "isolatedModules": true, | ||
| "jsx": "preserve", | ||
| "jsx": "react-jsx", |
There was a problem hiding this comment.
🧩 Analysis chain
Verify JSX runtime change is intentional and compatible with Next.js.
The change from "preserve" to "react-jsx" means TypeScript will transform JSX using React's automatic runtime. However, in Next.js projects, "preserve" is the standard setting because Next.js's compiler handles JSX transformation. Setting this to "react-jsx" could cause conflicts or double-transformation.
Is this change necessary for the Tailwind v4 upgrade? Please confirm this was intentional or revert to "preserve".
I'll help you verify this review comment. Let me gather information about Next.js JSX configuration best practices and check the actual project setup.
[/web_search]
[/run_scripts]
[/run_scripts]
🏁 Script executed:
#!/bin/bash
# Inspect the tsconfig.json to see the complete JSX and other relevant settings
cat tsconfig.json | head -50Length of output: 717
🏁 Script executed:
#!/bin/bash
# Check package.json for Next.js version and dependencies
jq '.dependencies, .devDependencies' package.json 2>/dev/null || echo "package.json structure:"
cat package.json | grep -A 5 '"next"' | head -10Length of output: 1261
🌐 Web query:
Next.js JSX TypeScript tsconfig setting preserve vs react-jsx
💡 Result:
Short answer
- "preserve": TypeScript leaves JSX syntax in the emitted files (no JSX transform) so a later tool (Babel/SWC/Next.js) will compile it. Next.js sets/uses "preserve" because it runs its own highly‑optimized JSX transform. [1][2]
- "react-jsx": TypeScript applies the React 17+ automatic JSX transform itself (emits calls to the react/jsx-runtime), so you don't need to import React in every file. This is useful for non‑Next builds or when you want TS to do the emit step. [3]
Recommendation for Next.js
- Keep "jsx": "preserve" in tsconfig.json for Next.js projects (Next configures/resets this automatically) so Next's SWC transform handles JSX. If you switch to "react-jsx" VS Code/editor warnings about missing React imports may disappear, but Next will usually reset tsconfig to "preserve" because it expects to run the transform itself. [1][2][4]
Sources
- Next.js TypeScript docs (tsconfig advice and Next’s behavior). [1]
- TypeScript JSX docs (explains preserve vs react-jsx semantics). [3]
- Community note about Next resetting jsx to preserve / editor interactions. [4]
References
[1] Next.js — TypeScript configuration/docs.
[2] Next.js — API/Configuration (TypeScript).
[3] TypeScript Handbook — JSX (preserve, react-jsx, etc.).
[4] Discussion: Next.js auto‑resets tsconfig.jsx to "preserve" (StackOverflow).
Revert "jsx" to "preserve" for Next.js compatibility.
In Next.js projects, the standard JSX setting is "preserve" because Next.js uses its SWC compiler to handle JSX transformation. Setting "jsx": "react-jsx" means TypeScript applies its own JSX transform, but Next.js typically resets this to "preserve" because it expects to run the transform itself. This setting change is unnecessary for the Tailwind v4 upgrade and may cause conflicts.
🤖 Prompt for AI Agents
In tsconfig.json around line 17, the "jsx" compiler option is set to "react-jsx"
which can conflict with Next.js's SWC-based JSX handling; revert this value to
"preserve" to allow Next.js to perform JSX transforms. Open tsconfig.json,
change the "jsx" property value from "react-jsx" back to "preserve", save, and
ensure there are no other tsconfig.* files or build scripts overriding this
setting so Next.js handles JSX transformation.
1 participant
tailwind.config.tstoglobals.cssSummary by CodeRabbit
Refactor
New Features
Bug Fixes
Chores