Tighter Tailwind integration, either built-in or via PostCSS support

[markdalgleish]

It'd be nice if Tailwind was more tightly integrated with Remix so you don't need to juggle package scripts to get it working.

I've experimented with this to get a feel for what an integration would look like and there are a couple of options that stick out. I started off aiming for built-in Tailwind support but ended up realising the better approach is probably via built-in PostCSS support. I've detailed both options below to provide a bit more context. It's also worth noting that built-in PostCSS support seems to be the most common way for frameworks to support Tailwind.

Option 1: Built-in Tailwind support

For the absolute minimum Tailwind setup we could include tailwindcss as a dependency of Remix, so all you'd need to do is add a tailwind.config.js file and then insert the @tailwind directives somewhere in your CSS.

/* app/styles/tailwind.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

What's nice is that this would be a non-breaking change since these directives are currently not valid in CSS that's passed directly to Remix.

There are a couple of concerns with it being this minimal:

• Consumers don't have control over the Tailwind version. This would be even worse if we start bundling our dependencies. We'd need to manage transitions between major Tailwind versions in the future which could be tricky.
• You won't have access to the types in your Tailwind config (/** @type {import('tailwindcss').Config} */) sincetailwindcss isn't a dependency of your project. We could re-export the type from Remix but that doesn't feel right to me.

One way to address these could be to support resolving the consumer's version of Tailwind. If this is the case, we could make a Tailwind dependency a requirement, or provide a default version internally as a fallback.

Option 2: Built-in PostCSS support

A different way to approach this which also addresses the prior concerns is to add PostCSS support.

To set up Tailwind via PostCSS in a fresh project, you'd first install dependencies.

npm install -D tailwindcss postcss

Then add a postcss.config.js with the Tailwind plugin.

module.exports = {
  "plugins": {
    "tailwindcss": {}
  }
};

Then add a tailwind.config.js.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./app/**/*.{ts,tsx,jsx,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
};

You'd then add the Tailwind directives somewhere in your CSS.

/* app/styles/tailwind.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

What's nice about this is that consumers now have a good place to hook in tools like Autoprefixer.

npm install -D autoprefixer

module.exports = {
  "plugins": {
    "tailwindcss": {},
    "autoprefixer": {}
  }
}

Since it's possible that Remix projects may already contain a postcss.config.js file as part of their custom tooling setup, we can't automatically enable PostCSS support when it's detected. This would need to be opt-in, at least until the next major release.

We still might want to provide autoprefixing by default so I consider this to be a separate proposal to #5017.

[sergiodxa]

One benefit of Tailwind support directly could be that the Tailwind CLI is faster than using it as a plugin of PostCSS AFAIK, so direct support instead of going through PostCSS could help keep a faster build.

[mikeybinns]

I don't like using tailwind, so I'd like to point out that whatever solution that's decided on should have a minimal impact for those who don't need it / want it.

While I understand the want to bundle in packages that you use so you don't need to create a boilerplate / separate CLI process each time, I prefer having Remix just be Remix, and then I can choose to add on the 3rd party packages that I choose to use, and we already have the "stacks" feature to be able to create your own starting point, one where you've already set up PostCSS / Tailwind already and npm-run-all or similar to run multiple CLI commands in parallel.

Perhaps a better option might be to make the compiler more extendable, but I'm sure that's a mammoth task, if it even is possible, but that would allow users to hook any package into the compiler (potentially releasing them as Remix plugins) and would leave the base compiler to just handle Remix.