`@tailwindcss/vite` discards `resolve.conditions` when resolving CSS `@import`, but honours them for JS

[jeffberry]

What version of Tailwind CSS are you using?

v4.3.3 (@tailwindcss/vite 4.3.3; also reproduces on 4.1.18)

What build tool are you using?

Vite 8 (the relevant code is unchanged across the plugin's ^5.2.0 || ^6 || ^7 || ^8 peer range)

Describe your issue

@tailwindcss/vite builds two resolvers. The JS one inherits the user's
resolve config as-is; the CSS one spreads that config and then overwrites
conditions with a hardcoded list:

// dist/index.mjs (4.3.3), lightly de-minified
let cssResolver = createIdResolver(config, {
  ...config.resolve,                                  // inherits alias, dedupe, …
  extensions: [".css"],
  mainFields: ["style"],
  conditions: ["style", "development|production"],    // ← replaces user conditions
  tryIndex: false,
  preferRelative: true,
})
let jsResolver = createIdResolver(config, config.resolve)   // ← conditions preserved

Because conditions is assigned after the spread, any custom condition set via
resolve.conditions is silently dropped for CSS @import, while continuing to
work for JS. The two resolvers therefore disagree about which copy of a package
they are looking at.

This is the standard monorepo setup where a library's exports map carries a
custom condition so a workbench/dev app consumes source while published
consumers get the build output:

// packages/my-lib/package.json
{
  "exports": {
    ".":           { "source": "./src/index.ts",  "default": "./dist/index.js" },
    "./style.css": { "source": "./src/style.css", "default": "./dist/style.css" }
  },
  "files": ["dist", "package.json"]
}

// apps/workbench/vite.config.js
export default {
  resolve: { conditions: ["source", ...] },
  plugins: [tailwindcss()],
}

/* apps/workbench/style.css */
@import "tailwindcss";
@import "my-lib/style.css";

/* packages/my-lib/src/style.css — copied verbatim to dist/ at build time */
@import "tailwindcss";
@source "./**/*.{ts,tsx,js}";   /* relative: src/ in the workspace, dist/ once published */

Expected

my-lib/style.css resolves through the source condition to
packages/my-lib/src/style.css, so its relative @source scans src/.

Actual

The source condition is discarded, resolution falls through to default, and
packages/my-lib/dist/style.css is loaded — so @source scans dist/.

The app therefore renders components from src/ while scanning dist/ for
class candidates. Any utility added since the last build is missing from the
generated CSS, and the only symptom is a component that renders unstyled. It
looks exactly like a broken component rather than a stale-cache problem, so it
is unusually expensive to diagnose — a rebuild makes it disappear, which also
makes it hard to reproduce reliably.

Worth noting there is no way to work around this from the exports map. Adding
a "style" condition (which the hardcoded list would match) does not help:
export conditions cannot distinguish in-repo from published consumption, and
src/ is not in files, so every published consumer would resolve to a path
that does not exist.

Suggested fix

Append rather than replace, so user conditions survive alongside the CSS-specific ones:

conditions: ["style", "development|production", ...(config.resolve.conditions ?? [])],

If overriding is deliberate, it would help to document it — the asymmetry with
the JS resolver two lines away reads as accidental.

Reproduction

Current workaround for anyone hitting this: bypass the export map and import the
library's CSS entry by relative path, so no condition resolution is involved.

[wook10]

Confirmed in source (not just the built output) — this pattern is duplicated in two places in packages/@tailwindcss-vite/src/index.ts, not one: the pre-Environment-API branch (config!.createResolver({...config!.resolve, ..., conditions: ['style', 'development|production'], ...})) and the newer Environment API branch (createBackCompatIdResolver(env.config, {...env.config.resolve, ..., conditions: [...], ...})). Both overwrite the spread-in conditions the same way, so a fix needs to touch both call sites (append the user's conditions instead of replacing them, e.g. conditions: ['style', 'development|production', ...(config.resolve.conditions ?? [])]).

I'd like to pick this up and send a PR that fixes both spots plus a regression test for the merged-conditions behavior — let me know if that sounds right.