Add Vite polyfills option#20036
Conversation
WalkthroughThis PR adds a 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/`@tailwindcss-vite/README.md:
- Line 80: Update the README paragraph about the polyfills option to clarify
that while Tailwind's default is to emit all supported CSS polyfills, CSS
Modules intentionally mask the AtProperty polyfill; mention that the `polyfills`
option controls emission but that `AtProperty` will be omitted when using CSS
Modules unless explicitly enabled, referencing the `polyfills` option and the
`AtProperty` polyfill name so readers can find the relevant behavior.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5ba356aa-0fca-455e-a068-f5eb916f3e45
📒 Files selected for processing (3)
integrations/vite/index.test.tspackages/@tailwindcss-vite/README.mdpackages/@tailwindcss-vite/src/index.ts
|
|
||
| ## Controlling Tailwind polyfills | ||
|
|
||
| By default, Tailwind emits all supported CSS polyfills. You can customize this behavior using the `polyfills` option: |
There was a problem hiding this comment.
Clarify default behavior for CSS Modules in this section.
The “emits all supported CSS polyfills” sentence is not fully accurate for CSS Modules, where AtProperty is intentionally masked. A short note here would prevent confusion.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/`@tailwindcss-vite/README.md at line 80, Update the README paragraph
about the polyfills option to clarify that while Tailwind's default is to emit
all supported CSS polyfills, CSS Modules intentionally mask the AtProperty
polyfill; mention that the `polyfills` option controls emission but that
`AtProperty` will be omitted when using CSS Modules unless explicitly enabled,
referencing the `polyfills` option and the `AtProperty` polyfill name so readers
can find the relevant behavior.
Confidence Score: 4/5The feature is additive and defaults to the existing behavior, so existing users are unaffected. The CSS-module guard correctly mirrors logic already in the webpack and PostCSS plugins. The core logic is correct and safe to merge. The main gaps are a missing test for the CSS-module AtProperty-stripping branch and incomplete README documentation for bitflag composition — both non-blocking quality concerns. The CSS-module branch in packages/@tailwindcss-vite/src/index.ts (lines 513–515) and the integration test file would benefit from an additional test case. Reviews (1): Last reviewed commit: "Add Vite polyfills option" | Re-trigger Greptile |
| polyfills: inputPath.endsWith('.module.css') | ||
| ? this.polyfills & ~Polyfills.AtProperty | ||
| : this.polyfills, |
There was a problem hiding this comment.
CSS module polyfill stripping is untested
The new branch that strips Polyfills.AtProperty for .module.css files is not covered by any integration test. The parallel webpack and postcss plugins have the same logic already, and the comment explains why it's necessary, but without a test exercising a .module.css file with the vite plugin the guard could be silently removed or regressed. A test that builds a .module.css input and asserts @layer properties is absent would close this gap.
|
|
||
| ## Controlling Tailwind polyfills | ||
|
|
||
| By default, Tailwind emits all supported CSS polyfills. You can customize this behavior using the `polyfills` option: | ||
|
|
||
| ```js | ||
| import tailwindcss from '@tailwindcss/vite' | ||
| import { defineConfig } from 'vite' | ||
| import { Polyfills } from 'tailwindcss' | ||
|
|
||
| export default defineConfig({ | ||
| plugins: [ | ||
| tailwindcss({ | ||
| // Disable all Tailwind polyfills | ||
| polyfills: Polyfills.None, | ||
| }), | ||
| ], |
There was a problem hiding this comment.
Only
Polyfills.None is shown; bitwise composition is undiscoverable
The README only demonstrates Polyfills.None. Because Polyfills is a bitflags enum (with AtProperty, ColorMix, and All), users who want to selectively disable just one polyfill (e.g., keep ColorMix but drop AtProperty) have no hint that they can pass Polyfills.ColorMix or Polyfills.AtProperty directly. A brief note or additional example showing per-flag control would make the API more discoverable.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Summary
Closes #20035, #20038
Test plan
Added integrations tests