PostCSS warning: plugin does not pass from option to postcss.parse with Vite + Tailwind CSS 4

[Codeer22]

Describe the bug
When running a Vite + React application in development mode with Tailwind CSS v4 and the @tailwindcss/postcss plugin, Vite prints the following warning during CSS processing:

A PostCSS plugin did not pass the from option to postcss.parse. This may cause imported assets to be incorrectly transformed. If you've recently added a PostCSS plugin that raised this warning, please contact the package author to fix the issue.

The development server starts successfully and the application loads, but the warning is consistently displayed when running npm run dev.

Environment
OS: Windows
Build tool: Vite
Vite: 8.2.2
Tailwind CSS: 4.3.3
@tailwindcss/postcss: 4.3.3
PostCSS: 8.5.26
Autoprefixer: 10.5.4
React: 19.2.8
TypeScript: 7.0.2
Package manager: npm

PostCSS configuration
export default {
plugins: {
"@tailwindcss/postcss": {},
},
}

[RobinMalfait]

Hey! Can you share a minimal reproduction repo so we can take a look?

Since you're using Vite, I would recommend to use @tailwindcss/vite instead.

[LeonxLJX]

I'd like to take this one. PostCSS plugin not passing the from option to postcss.parse is a known footgun: PostCSS uses from to resolve @import statements relatively. When Vite's PostCSS pipeline hands a Tailwind-rewritten CSS to PostCSS for processing (e.g. for @apply resolution), the from is undefined, so @import './foo.css' resolves against CWD instead of against the source file.

Root cause. In packages/@tailwindcss-postcss/src/index.ts (or wherever the @apply rewrite happens), postcss.parse(css, { from: undefined }) is the default. Vite passes the original file's path as from when calling the PostCSS plugin, but after Tailwind rewrites @apply to plain CSS, the resulting AST has imports that need to be resolved against the original source file's directory — not against CWD.

Alternatives I considered: (a) Pass the original from through to the rewritten AST's imports (smallest, IMO best). (b) Resolve all @import to absolute paths during the @apply rewrite (works but loses relative-path ergonomics for end users). (c) Document the limitation (workaround).

Suggestion to maintainer: (a) is the right fix. Two questions: (i) Does Vite's PostCSS pipeline pass the original from to the plugin chain, or does each plugin receive from set to the previous plugin's output? (ii) Is this a regression in Tailwind 4.x or present in 3.x too? I'd add a regression test that asserts @import './relative.css' resolves correctly inside an @apply-containing file. (claiming via @LeonxLJX)

[peppe1337]

I'm not the reporter, but I tried to build the minimal reproduction that was asked for and
could not get the warning to appear. Posting what I measured, since it also narrows down
where the message can come from.

Setup

Linux (headless), Node v22.22.3, npm 10.9.8, and exactly the versions from the report:
vite@8.2.2, tailwindcss@4.3.3, @tailwindcss/postcss@4.3.3, postcss@8.5.26,
autoprefixer@10.5.4, plus the postcss.config.js from the issue verbatim.

No warning, neither in vite build nor in dev with the page and the stylesheet actually
requested. Also no warning in these variants:

• @tailwindcss/postcss followed by autoprefixer
• autoprefixer alone
• a *.module.css containing a url(), so that both postcss-modules and Vite's URL
  rewriter are in the chain

Where the message comes from

It is Vite's own message, not PostCSS's and not Tailwind's — UrlRewritePostcssPlugin in
packages/vite/src/node/plugins/css.ts (tag v8.2.2; plugin at line 2093, the walk at
2106, the warning at 2109). It walks every declaration of the final AST and warns once if
the declaration has no source file:

root.walkDecls((declaration) => {
  const importer = declaration.source?.input.file
  if (!importer)
    opts.logger.warnOnce(
      '\nA PostCSS plugin did not pass the `from` option to `postcss.parse`. ' + ...

So the warning means: something in the chain left nodes in the tree that were parsed
without from, and those nodes were still there when Vite's URL rewriter ran last.

Why @tailwindcss/postcss doesn't look like it can be that something

I added a deliberately broken plugin that appends source-less nodes, and a diagnostic
plugin at the end of the chain that counts declarations with and without
source.input.file. These are the two files as used:

// broken-plugin.js
import postcss from 'postcss'
export default () => ({
  postcssPlugin: 'broken-on-purpose',
  Once(root) {
    root.append(postcss.parse('.broken-on-purpose{color:red}').nodes) // no { from }
  },
})

// diag-plugin.js
export default () => ({
  postcssPlugin: 'diagnose',
  OnceExit(root) {
    let withFrom = 0, withoutFrom = 0
    root.walkDecls(d => { d.source?.input.file ? withFrom++ : withoutFrom++ })
    console.log(`[diagnose] with from=${withFrom}  WITHOUT from=${withoutFrom}`)
  },
})

Same project, vite build, only the plugin order changed:

plugin order	diagnostic	Vite warning	.broken-on-purpose in emitted CSS
broken before @tailwindcss/postcss	with from=101 WITHOUT from=0	not printed	yes
broken after @tailwindcss/postcss	with from=100 WITHOUT from=1	printed	yes

The class survives into the emitted CSS in both rows, so in the first row the nodes aren't
being dropped — they're re-parsed. @tailwindcss/postcss@4.3.3 appears to rebuild the
document with a proper from, which means it doesn't just avoid producing source-less
nodes, it also normalises ones that were already in the tree. The same pattern shows up in
dev mode (77 / 0 vs 76 / 1 there — dev and build don't emit identical CSS, hence the
different totals).

The second row is also my positive control: it shows the setup can observe the warning, so
the negative results above are measurements rather than a silent failure. Without that row
I wouldn't post the negative result at all.

What I did not establish

I have not identified the plugin that actually causes it in the reporter's project, and I
can't rule out a different Tailwind code path that my CSS never hit. This only rules out
the plugin in the position the issue's config puts it in.

Suggestion for @Codeer22

The config in the issue lists only @tailwindcss/postcss, but the environment block also
lists autoprefixer, so the PostCSS chain Vite actually resolves may not be the one in the
paste. Three things worth checking:

1. which postcss.config.* Vite resolves. It starts at the project root and searches
   upward to the workspace root, and package.json (key postcss) is one of the search
   places — so if the file you're editing is not in the root Vite computed, a config
   further up is used instead.
2. a css.postcss option in vite.config.*, which replaces the file lookup entirely.
3. any plugin that runs after @tailwindcss/postcss.

Dropping the diagnose plugin above at the end of your chain will tell you whether the
source-less nodes exist at all in your build. To see which declarations they are, this
variant prints them:

export default () => ({
  postcssPlugin: 'diagnose',
  OnceExit(root) {
    root.walkDecls(d => {
      if (!d.source?.input.file)
        console.log('source-less:', d.parent?.selector ?? d.parent?.name, '{', d.prop, ':', d.value, '}')
    })
  },
})

The file set I used

package.json      { "type": "module", devDependencies as listed above }
postcss.config.js export default { plugins: { "@tailwindcss/postcss": {} } }
index.html        <link rel="stylesheet" href="/src/index.css"> + <div class="text-red-500">
src/index.css     @import "tailwindcss";