Description
My application has multiple sub-domains with very different use cases. While the sub-domains share some comment elements, each has a series of stylesheets that utilise @apply as part of a system to create reusable components.
The first step in migrating from Webpack was simple enough; instead of bundling Tailwind into stylesheets for each section, tailwind.css is shared across the sub-domains and the unique styles are kept in separate stylesheets.
When it came to ensuring the component CSS was compiled by Tailwind, however, I found the process a bit painful due to a lack of documentation. After seeing in the README that:
If you need to use a custom input or output file, you can run bundle exec tailwindcss to access the platform-specific executable, and give it your own build options.
I was able to use tailwindcss to compile the component stylesheets in development. When attempting to deploy, however, I encountered an exception running assets:precompile because Sprockets couldn't find the compiled stylesheets. It seemed that running that tailwindcss in production didn't fix the issue.
Digging into tailwindcss: build showed me that application.tailwind.css is hardcoded and so I ended up enhancing the task to compile any stylesheets that include ".tailwind" in the name.
I think the deployment process needs better documentation to avoid unfortunate surprises and, if there isn't currently a better way to compile other files, it would be nice to discuss creating a convention. While ".tailwind.css" is the reverse order to how Sprockets works, the idea of using file extensions as an indication that processing is required has already been established, maybe this could be expanded upon?