You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
I've now also enhanced the tailwindcss:watch task and am using listen to notice changes and then call tailwindcss:build. It's hardly elegant but it seems like it'll work until there is time for discussion.
I've also raised a feature request on the tailwindcss project asking for the CLI to support multiple inputs and outputs. While we could solve the issue just for this gem, it would probably be nicer if it was supported by the underlying CLI
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:
I was able to use
tailwindcss
to compile the component stylesheets in development. When attempting to deploy, however, I encountered an exception runningassets:precompile
because Sprockets couldn't find the compiled stylesheets. It seemed that running thattailwindcss
in production didn't fix the issue.Digging into
tailwindcss: build
showed me thatapplication.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?
The text was updated successfully, but these errors were encountered: