IntelliSense not working in shared package when used by other packages

[hugotiger]

What version of VS Code are you using?
v1.104.1

What version of Tailwind CSS IntelliSense are you using?
v0.14.29

What version of Tailwind CSS are you using?
4.1.17

What package manager are you using?
pnpm

What operating system are you using?
macOS

Tailwind CSS Stylesheet (v4) or config file (v3)

It's a monorepo, but only one main config file.

Main file:

@import "tailwindcss";

Example app/package usage:

@import "@repo/ui/globals.css";

VS Code settings
Used a vanilla setup to rule out any issues from weird settings, so basically it's:

{}

Reproduction URL
I've tried to create the simplest possible repro:
https://github.com/hugotiger/tailwindcss-intellisense-pnpm-monorepo-exports-bug/tree/main

Describe your issue
In a PNPM monorepo, I have a shared package that exports a CSS file containing the Tailwind config (e.g. globals.css). When that file is included in the exports field of the shared package’s package.json, Tailwind CSS Intellisense stops working inside the shared package.

I expect Intellisense to work in both the shared package (where the Tailwind setup lives) and in each app/package that consumes it. This pattern—centralizing Tailwind config and shared UI code—is pretty common in monorepos, and from reading the docs it sounds like this use-case should be supported (though I might be misunderstanding something).

I’ve found two things that make Intellisense start working again:

• Removing one of the example apps
• Removing globals.css from the shared package’s exports field

As a workaround, setting tailwindCSS.experimental.configFile in VSCode does restore Intellisense, but it'd be nice if this could be avoided!

I’m happy to provide more details, examples, or even help with fixing this issue if needed 😄

[thecrypticace]

This is indeed a bug but a bit of a complicated one to solve without potentially breaking other projects.

The short version is that we build a "graph" of used CSS files to determine what is a "root" file and what is not. In this case you have a file that is imported so we consider it something that isn't a root — even though, technically, it is but only for some files.

For a much simplified example, lets say you have these two files:

/* app.css */
@import "./tailwind.css";

@theme {
  --color-potato: potato;
}

/* tailwindcss.css */
@import tailwindcss";

We look at all CSS files with "interesting" bits in them and build up a graph. In this case tailwind.css contains the import for Tailwind CSS itself but if we used that file we'll be missing important theme variables. So we end up considering app.css to be the real root and that's what we load internally. Your case is very much the same situation except that you do want to consider a theoretical tailwind.css file to be the one that is loaded. But only when inside packages/ui.

I'll have to think through some heuristics to handle this case but will also need to be careful to not break other projects that don't make the same assumptions about where CSS files are located relative to their files.

[thecrypticace]

In the short term using a workspace settings file and the tailwindCSS.experimental.configFile setting is the way to go.

[hugotiger]

Thanks @thecrypticace for the detailed explanation! Seems rather tricky to solve...

I'll go with the workspace setting for now then. Let me know if I can be of any help fixing the issue 🤘