Should native Windows ARM64 standalone builds be restored in v4?

[MJRasicci]

Hi all,

I wanted to raise a discussion around restoring the native Windows ARM64 standalone CLI build in Tailwind v4.

Windows ARM64 standalone support existed in v3, via #10001, but it appears to have been lost in v4 during the migration from the old standalone-cli packaging flow to the newer Bun-based standalone build pipeline.

A few things make me think restoring it would be the right move:

• The current v4 standalone build script publishes Windows x64, but not a Windows ARM64 standalone binary.
• The current release workflow still builds Windows ARM64-native Oxide artifacts (aarch64-pc-windows-msvc) and copies them into the Windows ARM64 npm package path, so Windows ARM64 support still exists in part of v4.
• There is at least one report of downstream tooling expecting tailwindcss-windows-arm64.exe and failing because the asset no longer exists: Currently no windows-arm64.exe #17665. For transparency, I maintain Tailwind.MSBuild, which may have been the tool invoking the download in that report, although I have not received a corresponding issue in my own project.
• There is also at least one report suggesting the x64 standalone under emulation is not a complete substitute on Windows ARM64: tailwindcss-windows-x64.exe exits early in Windows ARM64 #19751 reports tailwindcss-windows-x64.exe exiting early or unreliably in --watch mode on Windows ARM64. More generally, my recollection from the original Add standalone-cli build for Windows Arm64 platform #10001 work is that x64 emulation was not a great substitute there either.

Yes, Windows can run the x64 binary through emulation, but native ARM64 would still be preferable because it:

• removes dependency on the emulation layer for standalone users
• restores a platform target that previously existed in v3 and supports the growing Windows on ARM ecosystem
• aligns better with the fact that v4 already ships Windows ARM64-native pieces elsewhere in the release pipeline
• avoids downstream tooling having to special-case or fail on a missing Windows ARM64 asset

Was the removal intentional? If not, would maintainers be open to restoring a native tailwindcss-windows-arm64.exe standalone release target?

If the maintainers are open to restoring it, I’d be happy to submit a PR for this myself.