f3fdda2a5c
Edit: some edits by @RobinMalfait --- ## Summary Fix a regression in `@tailwindcss/vite` introduced by `#19803` where JS plugin resolution could incorrectly resolve a package to its `browser` CSS entry. In cases like `daisyui`, Vite can resolve `@plugin "daisyui"` to `daisyui.css` instead of the package's JS entry, which causes Tailwind to try to load a CSS file as a JS plugin and fail with: ```txt Unknown file extension ".css" ``` This change keeps the `aliasOnly: false` behavior from `#19803` so tsconfig path resolution still works, but adds a JS-entry guard to `customJsResolver` in `@tailwindcss/vite`. If Vite resolves a plugin request to a non-JS file like `.css`, the custom resolver now returns `undefined` so Tailwind's internal fallback resolver can resolve the package as a JS plugin entry instead. I also added integration coverage for a package whose `main`/`module` points to JS while `browser` points to CSS, and verified that `@plugin "pkg"` still resolves to the JS entry in both build and dev mode. ## Test plan Added new integration tests in `integrations/vite/resolvers.test.ts` covering a package with: - `main` / `module` -> JS - `browser` -> CSS - `@plugin "pkg"` -> should resolve to JS, not CSS Verified with: ```sh pnpm test:integrations vite/resolvers.test.ts -t "browser points to CSS" pnpm test:integrations vite/resolvers.test.ts -t "resolves tsconfig paths" ``` These verify that: - `@plugin` no longer resolves to a CSS browser entry - the original tsconfig paths fix from `#19803` still works in both build and dev mode --- Maintainer edits: Instead of hardcoding file extensions, first try to resolve aliases and then fallback to the default resolving system we had before. We still check for a `.css` extension, even in the JS resolver because some dependencies (like `daisyUI`) put the CSS file there instead of in an `exports.style`. If we detect that, we still fallback to the default resolving logic. This should be compatible with the original issue we were trying to fix where we wanted to make Vite aliases work. Fixes: #19950 [ci-all] --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> |
||
|---|---|---|
| .. | ||
| src | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tsup.config.ts | ||
A utility-first CSS framework for rapidly building custom user interfaces.
Documentation
For full documentation, visit tailwindcss.com.
Community
For help, discussion about best practices, or feature ideas:
Discuss Tailwind CSS on GitHub
Contributing
If you're interested in contributing to Tailwind CSS, please read our contributing docs before submitting a pull request.
@tailwindcss/vite plugin API
Enabling or disabling Lightning CSS
By default, this plugin detects whether or not the CSS is being built for production by checking the NODE_ENV environment variable. When building for production Lightning CSS will be enabled otherwise it is disabled.
If you want to always enable or disable Lightning CSS the optimize option may be used:
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [
tailwindcss({
// Disable Lightning CSS optimization
optimize: false,
}),
],
})
It's also possible to keep Lightning CSS enabled but disable minification:
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [
tailwindcss({
// Enable Lightning CSS but disable minification
optimize: { minify: false },
}),
],
})