fix(vite): avoid resolving JS plugins to browser CSS entries

[ArcherGu]

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:

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:

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]

[coderabbitai]

Walkthrough

Added Vite resolver integration tests that verify Tailwind @plugin resolution prefers a package’s JavaScript entry over browser CSS entries when package.json uses browser or exports to point to CSS, covering both production build and dev server fetch scenarios. Updated the Vite resolver (customJsResolver) to first attempt alias-only JS resolution (accepting only absolute paths or .-relative results resolved against the base), fall back to full JS resolution if needed, and explicitly ignore resolved paths that end with .css.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: preventing JS plugins from being resolved to browser CSS entries in the Vite resolver.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description clearly describes the regression being fixed, explains the solution approach, and includes test coverage details and verification steps.

_{✏️ 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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

packages/@tailwindcss-vite/src/index.ts (1)

85-92: Optional: consider logging/debug when a JS plugin resolves to a non-JS file.

When customJsResolver receives an absolute, non-self-resolved path that fails isPotentialJsRootFile (e.g. the browser-field CSS case this PR targets), silently returning undefined lets Tailwind's internal fallback recover — which is exactly the desired behavior. However, if a future misconfiguration causes a plugin to resolve to, say, a .wasm or extensionless path, the silent rejection would be hard to diagnose. A DEBUG && log here would aid future debugging without affecting behavior.

Not blocking.

Also applies to: 142-149

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/`@tailwindcss-vite/src/index.ts around lines 85 - 92, In
customJsResolver, add a conditional debug log when jsResolver returns an
absolute path that is not the original id but fails isPotentialJsRootFile so the
function still returns undefined; specifically, after the check if
(!isPotentialJsRootFile(resolved)) return, log a DEBUG-level message (guarded by
a DEBUG flag or logger.isDebugEnabled) that includes the id, base, and resolved
values to aid debugging of mis-resolved plugins (referencing customJsResolver,
jsResolver, and isPotentialJsRootFile).

integrations/vite/resolvers.test.ts (1)

353-390: LGTM — build + dev coverage matches the rest of the suite.

Both tests assert the JS-entry-generated utility (browser-css-plugin) is present in the emitted CSS, which directly verifies the fix path. One nit: you could additionally assert that the CSS from the browser field (e.g. .should-not-be-loaded-as-a-plugin) is NOT present, to catch a future regression where the CSS file is erroneously inlined as a plugin. Optional.

🧪 Optional: add negative assertion

     await fs.expectFileToContain(filename, [candidate`browser-css-plugin`])
+    await fs.expectFileNotToContain(filename, ['should-not-be-loaded-as-a-plugin'])

(adjust to whatever negative-match helper the test utils expose)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@integrations/vite/resolvers.test.ts` around lines 353 - 390, Add a negative
assertion to both tests to ensure the CSS referenced by the package "browser"
field (e.g. the selector ".should-not-be-loaded-as-a-plugin") is NOT present in
the resolved styles; locate the tests titled 'resolves package plugins to JS
entries in production build when browser points to CSS' and 'resolves package
plugins to JS entries in dev mode when browser points to CSS' (using
browserCssPluginFixture), and after verifying the positive presence of
candidate`browser-css-plugin` use the same style-fetch/assert helpers
(fs.expectFileToContain for build and fetchStyles/retryAssertion for dev) to
assert the unwanted selector string is absent.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@integrations/vite/resolvers.test.ts`:
- Around line 353-390: Add a negative assertion to both tests to ensure the CSS
referenced by the package "browser" field (e.g. the selector
".should-not-be-loaded-as-a-plugin") is NOT present in the resolved styles;
locate the tests titled 'resolves package plugins to JS entries in production
build when browser points to CSS' and 'resolves package plugins to JS entries in
dev mode when browser points to CSS' (using browserCssPluginFixture), and after
verifying the positive presence of candidate`browser-css-plugin` use the same
style-fetch/assert helpers (fs.expectFileToContain for build and
fetchStyles/retryAssertion for dev) to assert the unwanted selector string is
absent.

In `@packages/`@tailwindcss-vite/src/index.ts:
- Around line 85-92: In customJsResolver, add a conditional debug log when
jsResolver returns an absolute path that is not the original id but fails
isPotentialJsRootFile so the function still returns undefined; specifically,
after the check if (!isPotentialJsRootFile(resolved)) return, log a DEBUG-level
message (guarded by a DEBUG flag or logger.isDebugEnabled) that includes the id,
base, and resolved values to aid debugging of mis-resolved plugins (referencing
customJsResolver, jsResolver, and isPotentialJsRootFile).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 75ca52d8-70e6-48ce-874f-72ac2ba45ddb

📥 Commits

Reviewing files that changed from the base of the PR and between 69ad7cc and 0d9ddac.

📒 Files selected for processing (2)

• integrations/vite/resolvers.test.ts
• packages/@tailwindcss-vite/src/index.ts

[coderabbitai]

🧹 Nitpick comments (1)

integrations/vite/resolvers.test.ts (1)

292-453: Optional: dedupe the two new tests' fixture.

The build and dev variants share an identical ~60-line fs fixture. Consider extracting the fixture to a shared const (or using describe.each([...]) with the build/dev runner bodies) to reduce the chance of the two tests drifting out of sync in future edits. Not blocking.

♻️ Sketch

const browserCssPluginFs = {
  'package.json': json`…`,
  'pnpm-workspace.yaml': yaml`…`,
  'packages/plugin-browser-css/package.json': json`…`,
  'packages/plugin-browser-css/index.js': js`…`,
  'packages/plugin-browser-css/browser.css': css`…`,
  'vite.config.ts': ts`…`,
  'index.html': html`…`,
  'src/index.css': css`
    `@import` 'tailwindcss';
    `@plugin` 'plugin-browser-css';
  `,
}

test('…production build…', { fs: browserCssPluginFs }, async ({ fs, exec, expect }) => { /* … */ })
test('…dev mode…',        { fs: browserCssPluginFs }, async ({ spawn, expect })     => { /* … */ })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@integrations/vite/resolvers.test.ts` around lines 292 - 453, Extract the
repeated fs fixture into a shared constant (e.g. browserCssPluginFs) and reuse
it in both tests instead of duplicating the ~60-line object; locate the two
tests titled "resolves package plugins to JS entries in production build when
browser points to CSS" and "resolves package plugins to JS entries in dev mode
when browser points to CSS" and replace their inline fs: { ... } blocks with fs:
browserCssPluginFs (or pass the const directly as the second argument), keeping
existing test bodies (exec/spawn/expect) unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@integrations/vite/resolvers.test.ts`:
- Around line 292-453: Extract the repeated fs fixture into a shared constant
(e.g. browserCssPluginFs) and reuse it in both tests instead of duplicating the
~60-line object; locate the two tests titled "resolves package plugins to JS
entries in production build when browser points to CSS" and "resolves package
plugins to JS entries in dev mode when browser points to CSS" and replace their
inline fs: { ... } blocks with fs: browserCssPluginFs (or pass the const
directly as the second argument), keeping existing test bodies
(exec/spawn/expect) unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ebdf78eb-aeb8-478a-9735-a803c5604a2b

📥 Commits

Reviewing files that changed from the base of the PR and between 0d9ddac and aad9694.

📒 Files selected for processing (2)

• integrations/vite/resolvers.test.ts
• packages/@tailwindcss-vite/src/index.ts

[RobinMalfait]

Additional tests from the reproduction provided in the linked issue is working now:

Additionally, verified with the original issue we tried to solve in 4.2.4 to make sure that still works as well:

The integration tests are also green where we test regressions for this, but needed to make sure these reproductions also still passed.

[RobinMalfait]

Thanks! Made some changes by removing the explicit extension list, and by trying to resolve the aliases first. Then fallback to the default resolving logic we used to have. If we resolve to a .css file in the JS resolvers we bail as well.

[JakubMindNexus]

Would be great to have it released - it's a small blocker for my library

[kenn]

same here, been waiting for this fix to be released. I hope 4.2.5 lands soon.