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.

[debanjanbasu]

Concrete consumer use case: Dioxus CLI builds invoke Tailwind as a standalone executable, and the Windows ARM64 path currently falls back to the x64 executable. Node.js is not a Dioxus runtime requirement; a native standalone asset keeps the build tool self-contained.

A bun-windows-arm64 build target, matching Windows ARM64 native package dependencies, checksum entry, and GitHub release asset would let Dioxus select the native binary. Bun 1.3.14 documents this cross-compilation target, and Tailwind already ships an ARM64 Windows Oxide package. I am preparing that focused change and will link the PR here.

[debanjanbasu]

Draft PR: #20552. It adds a native Windows ARM64 standalone executable, release asset, and architecture-aware CLI integration selection; local cross-build is blocked by Bun target runtime download networking, so CI will verify it.

[fouad-salehi]

Yes, native Windows ARM64 standalone builds should be restored.

The removal appears unintentional: v3 had it , v4's pipeline still builds ARM64 Oxide artifacts, but the standalone script only targets Windows x64 . Restoring it would fix downstream breakage (like your Tailwind.MSBuild) and provide a proper alternative to the flaky x64 emulation. A PR is definitely welcome.

[debanjanbasu]

Status update on #20552: the PR is rebased onto current main with no conflicts, and it now runs the CLI integration suite on a native windows-11-arm runner, so the ARM64 standalone binary gets build and watch coverage, alongside the release asset wiring. CI runs on the PR are queued pending maintainer approval.