Closes #32.
NativeMenus.setApplicationMenu() in bridge/core.ts sent bridge.request('menu.setApplicationMenu', { menu }) — a request-style call no zig handler serves. The menu bridge dispatches fire-and-forget actions (setAppMenu, addMenuItem, …); there is no menu.setApplicationMenu method on the native side at all. showContextMenu and updateMenuItem on the same class were dead the same way.
Nobody had hit the dead transport because nobody could: bridge/core is not re-exported from src/index.ts and package.json has no ./bridge export subpath, so the class was unreachable through the public API. Deleting it is not a breaking change — there was no way to import it.
Docs were pointing the other direction
docs/advanced/cross-platform.md showed:
mac.systemMenu.setApplicationMenu(menu)Neither systemMenu nor the craft-native/platform module it's imported from exists anywhere in this repo. Replaced with the real surface (window.craft.menu.set({ menus }) / onAction).
While in there: the rest of that section — mac.dock, mac.touchBar, win.taskbar, win.jumpList, linux.unity, linux.desktop — is fiction too, all of it under the same nonexistent craft-native/platform import. I did not delete it, since it plainly describes an intended API, but I moved it under a "Planned platform namespaces" heading that says so, so nobody else spends an afternoon looking for the module. Flagging rather than fixing, since designing that API is not this issue.
docs/BRIDGE_API.md documented only the tray menu. The application menubar — the thing #27 and #29 made actually work — had no documentation at all. It has a section now:
set()andonAction(), with the caveat thatset()replaces the default bar entirely, so an app with text input needs to declare Edit itself- the real item shape (
{ id, label, shortcut, icon, separator, role }) and the two things people get wrong: a separator is{ separator: true }not{ type: 'separator' }, and there are no nested submenus - the full role table, and why cut/copy/paste must be roles — a JS round trip cannot reach the field editor inside a text field, so an
iditem labelled "Copy" copies nothing
Verification
tsc --noEmitcleanbun test— 467 pass, 0 failbunx --bun pickierclean on both changed docs (the 36 warnings it reports repo-wide are all pre-existing, in files this PR does not touch)