wulkano
Rewrite using new Aperture and n-api
Implements the changes in https://github.com/wulkano/Aperture/pull/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.jsexport 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
@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
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.
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 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');
Sorry, missed the last comment on this. This looks really good now. I suggest just releasing it. It can be iterated on afterwards.
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:
I think that depends on the built tools, but ideally it should just work. We'll see I guess.
@karaggeorge Many thanks for such a cool upgrade to this library. Hoping it can get merged soon. ❤️
@sindresorhus sorry for the delay, addressed the last set of comments, needs a review to merge
I'll bump version and publish when it's in
I left the org, so I cannot leave a review, but it looks good to merge to me.
i'm curious why the original architecture is with sendEvent and what's the benefit of using NodeAPI in the new version? how do we anticipate things to improve? sometimes my app seems to be losing the events sent via "sendEvent", and I'm curious if this change will fix the issue for me.
