fix(vite): resolve tsconfig paths in CSS and JS resolvers by nightah · Pull Request #19803 · tailwindlabs/tailwindcss

nightah · 2026-03-15T09:29:32Z

Change aliasOnly from true to false when calling Vite's resolver so that the full resolution pipeline runs, including the oxc resolver responsible for tsconfig path resolution.

When aliasOnly was true, only the @rollup/plugin-alias plugin ran, which meant resolve.tsconfigPaths: true had no effect on CSS @import or JS @plugin resolution in @tailwindcss/vite.

Closes #19802.

Change `aliasOnly` from `true` to `false` when calling Vite's resolver so that the full resolution pipeline runs, including the oxc resolver responsible for tsconfig path resolution. When `aliasOnly` was `true`, only the @rollup/plugin-alias plugin ran, which meant `resolve.tsconfigPaths: true` had no effect on CSS `@import` or JS `@plugin` resolution in `@tailwindcss/vite`. Closes tailwindlabs#19802

coderabbitai · 2026-03-15T09:34:34Z

Caution

Review failed

Pull request was closed or merged during review

Walkthrough

The PR adds an import for json and two tests in integrations/vite/resolvers.test.ts that verify tsconfig path-alias resolution for both Vite production builds and dev server mode by asserting emitted CSS contains expected utilities. It updates packages/@tailwindcss-vite/src/index.ts: customCssResolver is now async, calls the underlying CSS resolver with a false flag and returns undefined for non-.css results; customJsResolver now calls the underlying JS resolver with false instead of true. The CHANGELOG is updated with a Fixed entry about tsconfig path alias resolution.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely summarizes the main change: fixing Vite's tsconfig path resolution in CSS and JS resolvers by changing the aliasOnly parameter.
Description check	✅ Passed	The description clearly explains the problem, root cause, and solution: changing aliasOnly from true to false to enable the full Vite resolution pipeline including tsconfig path support.
Linked Issues check	✅ Passed	The PR implementation addresses the core objective [`#19802`]: changing aliasOnly from true to false in both customCssResolver and customJsResolver to enable tsconfig path resolution. Test coverage validates the fix for both production and dev builds.
Out of Scope Changes check	✅ Passed	All changes are scoped to the stated objective: resolver parameter updates in index.ts, test cases validating tsconfig path resolution, and changelog documentation of the fix.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

📝 Coding Plan

Generate coding plan for human review comments

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

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

coderabbitai

🧹 Nitpick comments (1)

integrations/vite/resolvers.test.ts (1)
15-165: Optional: extract shared fixture setup to reduce duplication.

Both new tests repeat the same filesystem fixture; extracting a small helper/object for shared files would make future resolver test updates less error-prone.
🤖 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 15 - 165, Extract the
duplicated filesystem fixture used in the two tests titled "resolves tsconfig
paths in production build" and "resolves tsconfig paths in dev mode" into a
shared constant (e.g., sharedFs) and reference that constant in each test's
options instead of duplicating the object; update the tests to pass the sharedFs
to the test helper (replace the inline fs: { ... } blocks with fs: sharedFs) so
future changes to the fixture live in one place and both tests (production build
and dev mode) reuse the same setup.

🤖 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 15-165: Extract the duplicated filesystem fixture used in the two
tests titled "resolves tsconfig paths in production build" and "resolves
tsconfig paths in dev mode" into a shared constant (e.g., sharedFs) and
reference that constant in each test's options instead of duplicating the
object; update the tests to pass the sharedFs to the test helper (replace the
inline fs: { ... } blocks with fs: sharedFs) so future changes to the fixture
live in one place and both tests (production build and dev mode) reuse the same
setup.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: a1c6b6ce-a66b-41d5-a9dd-78be04245a20

📥 Commits

Reviewing files that changed from the base of the PR and between a4be983 and 12c1e7e.

📒 Files selected for processing (2)

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

RobinMalfait · 2026-03-16T15:04:11Z

Hey! Looks like CI is failing. Do you mind making sure that things work as expected? Thanks!

nightah · 2026-03-16T23:16:30Z

Thanks for the ping @RobinMalfait. I believe this is now fixed.

When aliasOnly was changed to false, the full Vite resolution pipeline could resolve bare specifiers like tailwindcss to JS entry points (e.g. lib.mjs) instead of CSS files. The enhanced-resolve fallback, which respects mainFields: ['style'], never ran.

That said, I'm unsure whether the remaining test failures are related to my change or an environmental issue.
Following the contribution guidelines after getting to pnpm build and pnpm test:integrations against a4be983 for a baseline, the following tests failed for me:

oxide/wasm.test.ts: wasm32-wasi loading (timeout)
postcss/source.test.ts: (these look like they didn't even fail in CI)
vite/nuxt.test.ts: build (timeout)
vite/qwik.test.ts: dev mode (pnpm install warning causing failure)

RobinMalfait

Running all the integration tests locally can result in issues when ports are already occupied. In CI, we split them so that doesn't happen. What I typically do locally is only run a single integration test at a time (typically the one I'm working on).

Since they pass in CI, I wouldn't worry about them locally 👍

Thanks for the contribution!

@RobinMalfait

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>

nightah requested a review from a team as a code owner March 15, 2026 09:29

coderabbitai Bot reviewed Mar 15, 2026

View reviewed changes

fix(vite): guard CSS resolver against non-CSS resolutions

941631b

update changelog

aead317

RobinMalfait approved these changes Mar 20, 2026

View reviewed changes

Merge branch 'main' into fix/vite-resolver-tsconfig-paths

acc1847

RobinMalfait enabled auto-merge (squash) March 20, 2026 15:14

RobinMalfait merged commit 5cb1efd into tailwindlabs:main Mar 20, 2026
9 checks passed

wyattjoh mentioned this pull request Apr 20, 2026

fix(e2e): drop unused @tailwindcss/typography from tanstack fixture clerk/cli#190

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(vite): resolve tsconfig paths in CSS and JS resolvers#19803

fix(vite): resolve tsconfig paths in CSS and JS resolvers#19803
RobinMalfait merged 4 commits intotailwindlabs:mainfrom
nightah:fix/vite-resolver-tsconfig-paths

nightah commented Mar 15, 2026

Uh oh!

coderabbitai Bot commented Mar 15, 2026 •

edited

Loading

Review failed

Uh oh!

coderabbitai Bot left a comment

Uh oh!

RobinMalfait commented Mar 16, 2026

Uh oh!

nightah commented Mar 16, 2026

Uh oh!

RobinMalfait left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

nightah commented Mar 15, 2026

Uh oh!

coderabbitai Bot commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review failed

Walkthrough

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

RobinMalfait commented Mar 16, 2026

Uh oh!

nightah commented Mar 16, 2026

Uh oh!

RobinMalfait left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented Mar 15, 2026 •

edited

Loading