Improve @tailwindcss/postcss performance for initial builds

[RobinMalfait]

This PR improves the performance of the @tailwindcss/postcss plugin. Before this change we created 2 compiler instances instead of a single one. On a project where a tailwindcss.config.ts file is used, this means that the timings look like this:

[@tailwindcss/postcss] Setup compiler: 137.525ms
⋮
[@tailwindcss/postcss] Setup compiler: 43.95ms

This means that with this small change, we can easily shave of ~50ms for initial PostCSS builds.

[RobinMalfait]

Pushed a few more changes to make CI pass. Some things I noticed and that the new commits solve:

1. The cache inside of the PostCSS plugin seems to be re-created from scratch, which means that we essentially have no cache. I hoisted it to the module-level to keep the cache around.
2. Noticed that we call onDependency with the same file twice, so made sure it's only in the list once. (This happened because resolving module dependencies of a file x, also included the file x)

So these new changes need a second pair of eyes before we can merge this.

/cc @adamwathan @philipp-spiess

[adamwathan]

The only thing I can think of here is that previously this was scoped for the opts argument to the tailwindcss function and now it's not, so now the cache is shared for the same key even if the options are different.

Interestingly the PostCSS docs explicitly say to set up caches in the place we were setting it up before:

Do we know with absolute certainty it was getting re-created from scratch on every save? 🤔

[RobinMalfait]

If I apply this diff to our plugin:

diff --git a/packages/@tailwindcss-postcss/src/index.ts b/packages/@tailwindcss-postcss/src/index.ts
index 7d18ddc36..43b824d2f 100644
--- a/packages/@tailwindcss-postcss/src/index.ts
+++ b/packages/@tailwindcss-postcss/src/index.ts
@@ -50,6 +50,8 @@ function tailwindcss(opts: PluginOptions = {}): AcceptedPlugin {
   let base = opts.base ?? process.cwd()
   let optimize = opts.optimize ?? process.env.NODE_ENV === 'production'
 
+  console.count('Setup caches here')
+
   return {
     postcssPlugin: '@tailwindcss/postcss',
     plugins: [
@@ -65,6 +67,7 @@ function tailwindcss(opts: PluginOptions = {}): AcceptedPlugin {
           let inputFile = result.opts.from ?? ''
           let context = cache.get(inputFile)
           let inputBasePath = path.dirname(path.resolve(inputFile))
+          console.count('Run @tailwindcss/postcss')
 
           async function createCompiler() {
             env.DEBUG && console.time('[@tailwindcss/postcss] Setup compiler')

If I then use it, the output looks like this:

You have the initial build, then 2 builds because of watch mode and because I made 2 changes.

Some notes / observations:

1. Not only is the Setup caches here log called every time we save, it's called twice for an unknown reason.
2. This is using the postcss-cli package

Next steps are to verify if this behaviour also happens in other environments where the PostCSS plugin is being used.

[RobinMalfait]

Can confirm that this behaviour also exists in a vite project with the PostCSS plugin:

[RobinMalfait]

Some updates for completeness:

If you structure your PostCSS config like this:

module.exports = {
  plugins: {
    '@tailwindcss/postcss': {},
  },
}

or this:

module.exports = {
  plugins: [
    require('@tailwindcss/postcss')
  ],
}

Then the above behavior can be observer. If you call your function (even without options) then you see the correct behavior:

module.exports = {
  plugins: [
    require('@tailwindcss/postcss')()
  ],
}

[ZuBB]

I might be running ahead of the train, but can this change (theoretically) be ported to v3? If so, what do maintainers think about it?

Every standalone run (read CI/CD cases) should be faster with it. IMO it deserves to be present in the latest stable branch

[adamwathan]

@ZuBB This isn't really relevant in v3 — completely different codebase and all of the caching we do there is already at the module scope level, so this is just an improvement over how v4 was working prior to this.

[ZuBB]

@ZuBB This isn't really relevant in v3 — completely different codebase and all of the caching we do there is already at the module scope level, so this is just an improvement over how v4 was working prior to this.

okay, I get it. thanks for the response

[thecrypticace]

I think we need to recreate the scanner when doing a full rebuild too, right? Since the globs might've changed?

[thecrypticace]

basically after line 166 we also want to re-create the scanner