@tailwindcss/webpack: scan imported node_modules files via Webpack module graph (parity with @tailwindcss/vite)

[Darshan-Naik]

Summary

@tailwindcss/vite walks Vite's module graph, so Tailwind classes referenced
inside imported files from node_modules are discovered automatically. The
same setup on @tailwindcss/webpack (official webpack loader) does not do
this — only files under the project's base directory are scanned.

This forces component library authors to either (a) ask every Webpack
consumer to add an explicit @source 'node_modules/<lib>/**/*.js'; to their
CSS, or (b) ship a CSS file that internally declares @source for the
library's own dist — which prevents per-component tree-shaking.

Current behavior

• Bundler: webpack 5.106.2
• Loader: @tailwindcss/webpack@4.2.4
• CSS: @import 'tailwindcss'; (no explicit @source)
• App: import { Button } from 'some-lib'; — Button.js contains
  className="bg-red-500"

Result: bg-red-500 is missing from the emitted CSS. Same repro on
@tailwindcss/vite emits it correctly.

Repro:

Data from a real design system

We tested this on an internal component library (~60 components, Tailwind
v4 tokens via @theme):

Setup	CSS size	Utilities from lib
@tailwindcss/vite + shim entry (no @source)	~8 KB	only imported components (works)
@tailwindcss/webpack + shim entry (no @source)	8 KB	0 (broken)
@tailwindcss/webpack + library-internal @source scan	102 KB	all 60 components (works but no tree-shake)

Why this matters

Component library authors currently can't offer a tree-shakeable CSS entry
point to Webpack consumers, because @source is static and authors can't
know ahead of time which of their components a given app imports. The Vite
plugin solves this via module-graph integration; the Webpack loader has no
equivalent.

Looking at @tailwindcss/webpack's source, this.addDependency() /
this.addContextDependency() are used for cache invalidation but not for
class discovery — the scanner still uses the static base directory.

Proposal

Expose a way for @tailwindcss/webpack to read Webpack's compilation
module graph (compilation.modules via compiler.hooks.thisCompilation)
and treat every module under node_modules that's currently in the graph
as a scan source. This would match @tailwindcss/vite's behavior and let
library authors ship tree-shakeable CSS entries on any bundler.

Happy to prototype if the team thinks the approach is viable.

[wongjn]

Since v4.0.8, @tailwindcss/vite doesn't walk Vite's module graph, as per #16631.

[Darshan-Naik]

@wongjn Thanks for the update,
what's the recommended path for component library authors who want to ship tree-shakeable utility CSS in Tailwind v4?

[wongjn]

You could:

• Maybe create a fork of Tailwind CSS that does tree shaking. Perhaps like your idea by using the module graph. Though this means consumers would need to use your fork instead of tailwindcss.
• Have individual CSS files per component that @source only itself. Though this can become a maintenance burden, and consumers would need to manually track and @import said CSS files.
• Write a Webpack plugin that loads a virtual CSS file with @source statements determined from the module graph. Though this would be an extra thing consumers would need to configure.