Whiteboard only packages for Apple Silicon today. I built and ran it on an Intel Mac (macOS 15.6, x86_64) with a small patch and would like to upstream it. Opening this first, as CONTRIBUTING.md asks, to check you want it before I send PRs.
Result: SKIP_NOTARIZE=1 pnpm --filter @dev.fast/review-desktop app:package:macos produces an unsigned VSCode-darwin-x64/Whiteboard.app, and scripts/smoke-launch-packaged.mjs passes on it (renderer and Review server up in 7.1s).
What it took (against c25f592):
package-macos.sh, notarize-macos.sh, smoke-launch-packaged.mjs: derive the arch from uname -m instead of requiring arm64. The Code OSS gulp tasks already have vscode-darwin-x64-min.curated-extensions.manifest.mjs: add darwin-x64 targets for rust-analyzer, C#, ty and ruff (same versions, Open VSX VSIXes, sha256 and size computed locally) and add darwin-x64 to supportedTargets.- diffr has no
x86_64-apple-darwin release. I built 0.1.3 from source (cargo build --release works as is) and skipped the diffr-fetch --check step on darwin-x64. That skip is a local workaround, not something to merge. The clean fix is for devdotfast/diffr to publish an x86_64-apple-darwin asset and pin it in @dev.fast/diffr's targets and pins.json, and then Whiteboard needs no special case.
One build gotcha: getProductionDependencies reads npm ls output, and npm redacts UUID-looking path segments as ***. A checkout under a path with a UUID in it then makes the dependency globs resolve to the Code OSS root, and packaging dies in build/lib/asar.ts with Cannot read properties of undefined (reading 'files'). It's unrelated to x64, but it cost me a rebuild.
Proposal: if you want Intel support, I'd send (a) a diffr PR adding the x86_64-apple-darwin release target, then (b) a Whiteboard PR with items 1 and 2 plus the pin. Whether to ship a signed x64 build or a universal binary on your release channel is your call. The PRs would only make local x64 packaging work. Happy to share the working patch here if useful.
Whiteboard only packages for Apple Silicon today. I built and ran it on an Intel Mac (macOS 15.6, x86_64) with a small patch and would like to upstream it. Opening this first, as CONTRIBUTING.md asks, to check you want it before I send PRs.
Result:
SKIP_NOTARIZE=1 pnpm --filter @dev.fast/review-desktop app:package:macosproduces an unsignedVSCode-darwin-x64/Whiteboard.app, andscripts/smoke-launch-packaged.mjspasses on it (renderer and Review server up in 7.1s).What it took (against c25f592):
package-macos.sh,notarize-macos.sh,smoke-launch-packaged.mjs: derive the arch fromuname -minstead of requiring arm64. The Code OSS gulp tasks already havevscode-darwin-x64-min.curated-extensions.manifest.mjs: adddarwin-x64targets for rust-analyzer, C#, ty and ruff (same versions, Open VSX VSIXes, sha256 and size computed locally) and adddarwin-x64tosupportedTargets.x86_64-apple-darwinrelease. I built 0.1.3 from source (cargo build --releaseworks as is) and skipped thediffr-fetch --checkstep on darwin-x64. That skip is a local workaround, not something to merge. The clean fix is for devdotfast/diffr to publish anx86_64-apple-darwinasset and pin it in@dev.fast/diffr'stargetsandpins.json, and then Whiteboard needs no special case.One build gotcha:
getProductionDependenciesreadsnpm lsoutput, and npm redacts UUID-looking path segments as***. A checkout under a path with a UUID in it then makes the dependency globs resolve to the Code OSS root, and packaging dies inbuild/lib/asar.tswithCannot read properties of undefined (reading 'files'). It's unrelated to x64, but it cost me a rebuild.Proposal: if you want Intel support, I'd send (a) a diffr PR adding the
x86_64-apple-darwinrelease target, then (b) a Whiteboard PR with items 1 and 2 plus the pin. Whether to ship a signed x64 build or a universal binary on your release channel is your call. The PRs would only make local x64 packaging work. Happy to share the working patch here if useful.