When an esoteric bug gives you a crisis of confidence.

I'm building a little toy / passion project app for saving bookmarks and archiving what they link to. It's Ruby on Rails, with TailwindCSS and Phlex components. It's very vanilla Rails.

When I built a cross platform image for it on my ARM64 Mac, and deployed it on an AMD64, here's what it looked like.

It seems that, when building the container, somehow some styles were missing. But why? There followed hours of debugging, grilling Claude Code who eventually goes around in circles - when not mixing up Tailwind 3 and Tailwind 4 syntax.

Side note: I think I'm starting to recognise when an LLM is not going to be able to complete the request / solve the problem - after somewhere between 3 and 5 attempts to do the job it's unlikely to solve it and you'll need to take the keyboard back from your AI pair programming partner and debug it like they did in ages past. I know, I know - it's so 2024!

Debugging it was slow and painful, since I was building docker images, pushing them into a repository, then pulling them down into a VPS.

In the default Dockerfile for Rails, there's a command which builds all the CSS and JS assets so they can be served up : bin/rails assets:precompile When I connected to the container in production, I could run that command and the CSS would be successfully generated and the site's CSS was complete. So, the bug was during the build of a Docker Image.

After enough searching, I found this Tailwind Bug: Styles aren't generated when building a Docker image for ARM64 on a 2019 Intel MacBook Pro #17728

Here's the comment which describes what happens.

Hey!

So we did a bunch of testing and figured out the bug, or at least how to give you a workaround. More in depth information here: oven-sh/bun#19677

Turns out that:

If you are on an M1
Using Docker
With Apple Virtualization framework
With the Use Rosetta for x86_64/amd64 emulation on Apple Silicon option checked
Running a Docker file with --platform=linux/x86_64
If you then have values such as 0.25 or 1.25, then they all get truncated to just 0 and 1 respectively.
I don't think there is anything we can do to solve this issue unfortunately.

However, if you go into your Docker settings under the Virtual Machine Options settings, then you can either:

Uncheck the Use Rosetta for x86_64/amd64 emulation on Apple Silicon option
Switch to QEMU (Legacy)
Switch to Docker VMM
How this bug relates to Tailwind CSS itself:

One of the checks we do internally when you use px-4, is that we check if the value 4 is a valid multiplier of 0.25 because we don't want to support px-4.123 for example. The 0.25 gets turned into 0 so our check doing 4 % 0.25 === 0 now becomes 4 % 0 === 0 instead. 4 % 0.25 correctly produces 0, but 4 % 0 produces NaN which is not 0 of course and therefore the px-4 is ignored because we consider it invalid.

This is also why other classes did work like a bg-red-500 or flex because they are not dealing with numbers.

Hopefully any of these workarounds will work for you.

That's a crazy bug, that makes you feel crazy hunting it. "How can I not make this very simple thing work‽" It turns out, there is a reason, and discovering it was quite the relief!