Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploying multiple stylesheets #151

Closed
HashNotAdam opened this issue Feb 25, 2022 · 2 comments
Closed

Deploying multiple stylesheets #151

HashNotAdam opened this issue Feb 25, 2022 · 2 comments

Comments

@HashNotAdam
Copy link

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?

@HashNotAdam
Copy link
Author

HashNotAdam commented Feb 28, 2022

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.

task tailwind_watch: :environment do
  Listen.to(
    "app/components",
    "app/helpers",
    "app/javascript",
    "app/assets/stylesheets",
    "app/views"
  ) do |_modified, _added, _removed|
    Rake::Task["tailwindcss:build"].execute
  end.start
end

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

@flavorjones
Copy link
Member

Let's consolidate this conversation into one place: #355

@flavorjones flavorjones closed this as not planned Won't fix, can't repro, duplicate, stale Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants