[FR]: Add windows support for CLI versions > 5.5.0

[RobertDiebels]

What is the current behavior?

According to the docs:
"Windows releases are no longer published as of v5.5.0. This is due to a new dependency on go-tree-sitter which has a CGO dependency that makes cross compiling to Windows difficult."

Describe the feature

I would like to have Windows support for Aspect CLI. I'm trying to build the most recent version of rules_ts and it fails due to a dependency on Aspect CLI.

I've looked in the treesitter-go repository, but there is no open issue that mentions cross-compilation failure. I realize that this an upstream issue, but if you could at least file an issue with them detailing the issue then they can have a look at it.

[alexeagle]

Yeah, this is a problem, we haven't had time to dig into it. A bug bounty would be helpful here, since we don't have many Bazel users on Windows asking for it.

[RobertDiebels]

@alexeagle Is there anything I can do to move this along? I'm willing and able to create a PR, I just need a nudge into the right direction, which might undercut the need for funding.

[alexeagle]

Sure, the hard part is cross-compiling the Go binary including cgo dependencies.
Without that we could try some GHA release automation changes to build the exe on a Windows runner, though process changes are harder to contribute

[RobertDiebels]

@alexeagle Does Aspect cross-compile the Go binary? Or is this done elsewhere? Could you point me to where this occurs so I can take a look at it?

[alexeagle]

You can build the //release package, see https://github.com/aspect-build/aspect-cli/blob/main/release/release.bzl#L38

[RobertDiebels]

@alexeagle Awesome thank you, do you think it would be worth trying to swap out the llvm toolchain for the zig-based hermetic_cc_toolchain from Uber?

Zig isn't as battle-tested as LLVM, but their compiler has CC as a first-class use case and they released version 0.12.0 2 days ago.

I'd like to check with you before I attempt to swap out LLVM to make sure you'd be willing to adopt zig (either partially just for windows, or fully for all binaries) as not to waste time/effort in an attempt.

[alexeagle]

This repo is synced with our internal monorepo so changing the toolchain is likely breaking for something else, and so this is an area where it's hard for us to accept external contribution.
All things equal I think I'm more comfortable relying on GHA windows machines for releases rather than more complexity in our Bazel toolchain. @gregmagolan WDYT?