feat(javascript): publish a win32-arm64 native package

[prmoore77]

Fixes #4629.

Generated-by: Claude Code

[lidavidm]

@prmoore77 (not Claude) do you have an ARM device and can you participate in release verification? I don't think anyone currently has such a device so we can't test the final binaries.

[prmoore77]

@prmoore77 (not Claude) do you have an ARM device and can you participate in release verification? I don't think anyone currently has such a device so we can't test the final binaries.

Hi @lidavidm - yes - I use a Windows arm64 VM in Azure Cloud for testing this type of stuff. I would be glad to test this manually on there.

[CurtHagenlocher]

FWIW, I also have a Windows ARM device (and a bad habit of not participating in release validation :( ).

[lidavidm]

Well, the Windows script also doesn't test binaries yet (I'm building up to that in #4624), so this adds pressure on me to finish that 😔

[Copilot]

Pull request overview

Adds Windows-on-ARM64 support to the JavaScript ADBC driver-manager by extending the native build/release matrix and introducing a new platform-specific npm package for win32-arm64-msvc.

Changes:

• Add aarch64-pc-windows-msvc to the @napi-rs/cli target list and configure Rust static CRT flags for that target.
• Introduce a new optional dependency/package: @apache-arrow/adbc-driver-manager-win32-arm64-msvc.
• Extend GitHub Actions build/packaging workflows to build/test on windows-11-arm, including a vcpkg-based SQLite dependency path for ARM64.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
javascript/package.json	Adds the Windows ARM64 Rust target and declares the new platform optional dependency.
javascript/package-lock.json	Updates the lockfile optionalDependencies list to include the new win32-arm64 package.
javascript/npm/win32-arm64-msvc/README.md	Adds README for the new Windows ARM64 native package.
javascript/npm/win32-arm64-msvc/package.json	Defines the new scoped npm package for the Windows ARM64 native addon.
javascript/.cargo/config.toml	Adds Windows ARM64 target rustflags (static CRT).
.github/workflows/packaging.yml	Adds a windows-11-arm leg to the Node.js binaries packaging matrix.
.github/workflows/javascript.yml	Adds windows-11-arm to build/test matrices and uses vcpkg to supply SQLite on Windows ARM64.

Files not reviewed (1)

• javascript/package-lock.json: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[prmoore77]

This is pre-existing behavior shared by every test leg, not specific to
ARM64: all five existing platform packages are also unpublished at 0.25.0,
and npm treats unresolvable optional dependencies as skippable. The ARM64
leg passed CI with the package absent from the registry.

[prmoore77]

With the micromamba rework, CONDA_PREFIX is now defined on the ARM64 leg
too (pointing at the micromamba env), and its Library\bin on PATH is
needed there for sqlite3.dll, so the shared step is correct for both
Windows legs.

[eitsupi]

It seems that micromamba release arm64 Windows binaries.
https://github.com/mamba-org/micromamba-releases/releases/tag/2.8.1-0

Is there a possibility that this could be used as an alternative to Miniforge?

[lidavidm]

As @eitsupi points out if we can use setup-micromamba and stay consistent that would be ideal.

[prmoore77]

Done — the win-arm64 test leg now uses the conda-forge flow via micromamba
instead of vcpkg (562b35c). Two notes on the implementation:

• mamba-org/setup-micromamba is not on the ASF actions allowlist
  (approved_patterns.yml
  only has conda-incubator/setup-miniconda), so the step downloads the
  official micromamba-win-arm64.exe from mamba-org/micromamba-releases
  directly, pinned to 2.8.1-0 with a sha256 check. If you'd rather get
  setup-micromamba added to the allowlist and use the action, happy to
  switch — this seemed like the lower-friction path for now.
• conda-forge's win-arm64 platform doesn't have cmake, compilers,
  libpq, or pkg-config yet, so the leg installs just libsqlite (what
  the test driver build needs) and uses the runner's preinstalled MSVC and
  CMake rather than the full ci/conda_env_cpp.txt.

[lidavidm]

I don't really want to work around the allowlist...we should get it added.

[prmoore77]

Manual verification on Windows-on-ARM done, per the release-verification question above.

I took the npm tarballs built by this PR's packaging run (the node-packages artifact from run 30506435560 — the main @apache-arrow/adbc-driver-manager package plus the new win32-arm64-msvc platform package) and installed them on a native Windows arm64 VM (Azure, Node.js v24.18.1 arm64). The driver manager then loaded a native win_arm64 ADBC driver (gizmosql-adbc v2.0.4) and ran a query over TLS against a GizmoSQL server also running natively on the same Windows arm64 box (DuckDB backend, TPC-H sf=0.1 data loaded):

platform: win32 arch: arm64 node: v24.18.1
native addon: ...\node_modules\@apache-arrow\adbc-driver-manager-win32-arm64-msvc\adbc-driver-manager.win32-arm64-msvc.node
driver: ...\libadbc_driver_gizmosql-v2.0.4-windows_arm64\libadbc_driver_gizmosql.dll
uri:    gizmosql://localhost:31337
row: {"one":1,"backend_version":"v1.5.5"}
PASS: @apache-arrow/adbc-driver-manager loaded the native arm64 addon and executed a query through libadbc_driver_gizmosql.dll

So the CI-built artifacts work end-to-end on Windows arm64: addon load → driver load → TLS connect → query → Arrow results, with every component (Node, addon, driver, server) running natively on arm64. I'm happy to repeat this against the actual release candidates during release verification, I have this VM available all of the time (though it is shut down when I'm not using it for testing).

[prmoore77]

@lidavidm - if you would like me to run the Azure Windows arm64 VM for you - and provide credentials - just let me know... thanks.