Rewrite using new Aperture and n-api #34
Conversation
|
@sindresorhus Any idea why when I ran this with the Building with I didn't have any such issues using the Could we do something similar to Kap, run the build in two workers one for arm and one for intel, generate two Or is there value in keeping the CLI version in general |
| ) | ||
| ], | ||
| dependencies: [ | ||
| .package(url: "https://github.com/wulkano/Aperture", from: "2.0.1"), | ||
| .package(url: "https://github.com/apple/swift-argument-parser", from: "1.3.1") | ||
| .package(url: "https://github.com/wulkano/Aperture", branch: "george/rewrite-in-screen-capture-kit"), |
There was a problem hiding this comment.
The branch here should change back to the real version when the Aperture PR is merged/released
Using new properties only works with a new Xcode, which may require the latest macOS image. |
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. |
| @@ -3,30 +3,22 @@ import Aperture | |||
|
|
|||
| struct Options: Decodable { | |||
| let destination: URL | |||
| let targetId: String? | |||
There was a problem hiding this comment.
| let targetId: String? | |
| let targetID: String? |
| applicationName?: string; | ||
| applicationBundleIdentifier?: string; |
There was a problem hiding this comment.
Nitpick (my preference only):
| applicationName?: string; | |
| applicationBundleIdentifier?: string; | |
| appName?: string; | |
| appBundleIdentifier?: string; |
Implements the changes in wulkano/Aperture#80
node-swift)native.jsexport that uses that add-onFor now, kept the other as the default, since the add-on can't be cross-platform compiled until this is released