Skip to content

Some classes are not generated in Ruby/HAML since upgrading to Tailwind 4 #17813

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

Closed
jeremybdk opened this issue Apr 28, 2025 · 11 comments · Fixed by #17846
Closed

Some classes are not generated in Ruby/HAML since upgrading to Tailwind 4 #17813

jeremybdk opened this issue Apr 28, 2025 · 11 comments · Fixed by #17846
Assignees

Comments

@jeremybdk
Copy link

jeremybdk commented Apr 28, 2025

What version of Tailwind CSS are you using?

4.1.4

What build tool (or framework if it abstracts the build tool) are you using?

Standalone CLI

What version of Node.js are you using?

20.19

What browser are you using?

N/A

What operating system are you using?

N/A

Reproduction URL

https://github.com/jeremybdk/tailwindhaml

Describe your issue

We are using custom classes like "w-[16px] h-[16px]" sometimes in ruby variable used in partials.
But it seems that they are not parsed correctly anymore since switching to Tailwind 4. We never had that issue on Tailwind 3.

I've added a small sample of a haml file that in my opinion should be parsed correctly and as you can see in the output some of the used classes like "w-[16px] h-[16px]" and "w-[12px] h-[12px]" are not included in the output.css while w-[20px] h-[20px] are included in the output.css

thank you

@adamwathan
Copy link
Member

Thanks, can confirm we're not picking these classes up properly using some internal tooling:

Image

Will investigate!

@jeremybdk
Copy link
Author

Thanks,
I was searching for this tool to test our code but now I know it's an internal tool 😅

@roberto-souza

This comment has been minimized.

@magnum
Copy link

magnum commented May 1, 2025

I am experiencing a similar issue as described in this comment: rails/tailwindcss-rails#533 (comment). Not all the expected CSS classes are generated when building locally on macOS with Docker using Kamal. Thanks to this suggestion: rails/tailwindcss-rails#499 (comment), there's workaround by building the Docker image on x86_64, as macOS defaults to using the arm64 architecture. Could these two issues be related?

@RobinMalfait
Copy link
Member

I am experiencing a similar issue as described in this comment: rails/tailwindcss-rails#533 (comment). Not all the expected CSS classes are generated when building locally on macOS with Docker using Kamal. Thanks to this suggestion: rails/tailwindcss-rails#499 (comment), there's workaround by building the Docker image on x86_64, as macOS defaults to using the arm64 architecture. Could these two issues be related?

@magnum that seems unrelated to me. The issue described here is about how classes are extracted. In your linked comment I see that you wrote When I run the application locally, it functions correctly. but there are no development/production/local/... differences in the extractor.

I would suggest to open a new issue with a minimal reproduction repo and all the information available so we can take a look.

@magnum
Copy link

magnum commented May 2, 2025

regarding the part

but there are no development/production/local/... differences in the extractor.

I believe the issue lies with the extractor when it is run inside a Docker container on the arm64 architecture, similar to its operation on macOS locally. Could it be related in that manner?

@jeremybdk
Copy link
Author

For us we have the same issue on macOS, or when deploying on Heroku (Linux) servers so it's not a platform issue on our side

@RobinMalfait
Copy link
Member

regarding the part

but there are no development/production/local/... differences in the extractor.

I believe the issue lies with the extractor when it is run inside a Docker container on the arm64 architecture, similar to its operation on macOS locally. Could it be related in that manner?

@magnum hmm maybe? A minimal reproduction repo would be very helpful to take a look!

For us we have the same issue on macOS, or when deploying on Heroku (Linux) servers so it's not a platform issue on our side

@jeremybdk yep that makes sense because it's an actual bug. Will be fixed by #17846

@magnum
Copy link

magnum commented May 2, 2025

@RobinMalfait i have created a repository and attempted to include instructions for reproduction.
https://github.com/magnum/tailwindcss-issue17813
thanks for the support

RobinMalfait added a commit that referenced this issue May 5, 2025
This PR fixes and improves the HAML extractor by ensuring that whenever
we detect lines or blocks of Ruby code (`-`, `=` and `~`) characters at
the beginning of the line, we treat them as Ruby code.

Fixes: #17813

## Test Plan

1. Existing tests pass
2. Changed 1 existing test which embedded Ruby syntax
3. Added a dedicated test to ensure the HAML file in the linked issue is
parsed correctly

Running this in the internal extractor tool you can see that the
`w-[12px]`, `w-[16px]`, `h-[12px]`, and `h-[16px]` are properly
extracted.

Note: the `mr-12px` is also extracted, but not highlighted because this
is not a valid Tailwind CSS class.

<img width="1816" alt="image"
src="https://github.com/user-attachments/assets/fc5929ca-bc71-47d2-b21b-7abeec86f54d"
/>
@RobinMalfait
Copy link
Member

Hey!

This has been fixed by #17846 and will be available in the next release.


@magnum sweet, I believe this is a separate issue either way. Do you mind opening an issue with that link attached so we can solve and track it separately?

@RomainLanz
Copy link

Thanks, can confirm we're not picking these classes up properly using some internal tooling:
Image

Will investigate!

This tools look interesting! I have a similar issue using Vue and it will be wonderful to have it to quickly reproduce the issue. 😄

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

Successfully merging a pull request may close this issue.

6 participants