Rewrite using new Aperture and n-api

[karaggeorge]

Implements the changes in wulkano/Aperture#80

• Adds support for the new APIs
• Allows multiple recorders to be running at the same time
• Adapts the TS types to support multiple recording types
• Adds a Node add-on target (using node-swift)
• Adds a native.js export that uses that add-on

For now, kept the other as the default, since the add-on can't be cross-platform compiled until this is released

[karaggeorge]

@sindresorhus Any idea why when I ran this with the macos-14 image I got errors for missing properties. They are marked with if #avalable(macOS 15) 🤔

Building with macos-15 worked, but failed the tests. I got those failures intermittently locally too, still not sure why they happen. It only happens for the CLI, I think something to do with the way I use async with the run loop. I'll debug a bit more tonight

I didn't have any such issues using the aperture.node bindings, but I couldn't get rid of the CLI since I can't build it cross-platform

Could we do something similar to Kap, run the build in two workers one for arm and one for intel, generate two .node files and require them conditionally at runtime?

Or is there value in keeping the CLI version in general

[karaggeorge]

The branch here should change back to the real version when the Aperture PR is merged/released

[sindresorhus]

Any idea why when I ran this with the macos-14 image I got errors for missing properties. They are marked with if #avalable(macOS 15) 🤔

Using new properties only works with a new Xcode, which may require the latest macOS image. #avalable(macOS 15) means it will be ignored when running on older macOS versions, but you still need latest Xcode with latest SDK to build it.

[sindresorhus]

For now, kept the other as the default, since the add-on can't be cross-platform compiled until this is released

The goal should be to only have the native add-on. Doesn't make sense to maintain both. And the native add-on should be much faster and reliable.

[sindresorhus]

Suggested change

	let targetId: String?
	let targetID: String?

[sindresorhus]

Nitpick (my preference only):

Suggested change

	applicationName?: string;
	applicationBundleIdentifier?: string;
	appName?: string;
	appBundleIdentifier?: string;

[karaggeorge]

@sindresorhus I think this is ready for another review

I've managed to build a cross-platform add-on, although we have to use xcodebuild for now, until this is available

It means that we need this entire build directory included, otherwise it throws when imported:

I've set up GH actions to build/test in arm macos-15 and upload the add-on as an artifact, then download and run tests on an intel macos-13 image (the only free intel one). Currently I'm skipping the recording test since they have some issues with recording permissions that I doubt they'll fix for such an old image, but even just running the other ones verifies the add-on is compatible with intel

Changed the API of the package a bit to have separate entry-points for each target since they have different sets of options. It was either that, or a complex TS overload, figured this was better, but not a strong preference.

One thing I'm not sure about is do we need to do anything for ASAR with the add-on path like we did for the CLI? Or is that ok as is with:
const nativeModule = createRequire(import.meta.url)('./build/aperture.framework/Versions/A/aperture.node');