Add aarch64 binaries

[mcgordonite]

Motivation

Implements #46.

Approach

The native binaries for both arm64 and x64 are shipped in the package's dist directory:

dist
├── arm64
│   ├── ctrlc-windows.node
│   └── process-killer.exe
└── x64
    ├── ctrlc-windows.node
    └── process-killer.exe

Previously, only x64 binaries were available. Also:

• index.js loads the module for the correct architecture at runtime.
• A JS build script runs napi build for a particular architecture then moves the artifacts to the correct path in dist. By default, this builds for the host system.
• CI is updated to build for both platforms.

A package created from a slightly modified version of the CI in this repo on both platforms, but I've not been able to test the full release CI on my fork.

Alternate Designs

I suggested using napi-rs's default build approach in #46. This would publish two additional platform-specific packages to NPM: ctrlc-windows-x64 and ctrlc-windows-arm64. This turned out to be quite hard, partly due to the additional process-killer.exe binary. I couldn't get napi-rs's CLI to copy it to the correct path, meaning we'd need a build script anyway.

The downside is shipping an extra 180KB in the package. Hopefully this is worth it to avoid the extra build and consumer complexity.

[changeset-bot]

🦋 Changeset detected

Latest commit: 06dabc0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
ctrlc-windows	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jburggraaf]

I have been looking into doing exactly what this library does but I need arm support to see if it works for my project. Thanks for PR.

[cowboyd]

We need to look into why this is failing. I'll try and pull the source later today.

[jbolda]

I don't think it would add consumer complexity, but it would require adjustments and that we make certain to thread the needle with the right dependency structure. napi-rs should help us with this, but it doesn't seem worth blocking this longer.

We can came back and address this with separate packages (and likely updated dependencies) in the next version.

[cowboyd]

@jbolda Any idea why the checks aren't running?

[jbolda]

You need to approve as I apparently don't have write access.

[cowboyd]

@jbolda You are listed as a maintainer, as well as all of our engineering team. I think the problem was that the "new" merge experience doesn't actually let you run workflows or something? What if you try now ( I switched it back to "classic").