refactor: stop bundling frontman-core into framework wrappers

[BlueHotDog]

Summary

• Externalize @frontman-ai/frontman-core from tsup bundles in all framework wrappers (nextjs, astro, vite) — moved from noExternal to external
• Move @frontman-ai/frontman-core from devDependencies to dependencies so npm/yarn installs it (and all transitive deps) automatically for consumers
• Remove re-declared transitive deps (lighthouse, chrome-launcher) from each wrapper's package.json — they propagate via frontman-core
• Make @frontman/bindings publishable — removed "private": true, added publish metadata, prepublishOnly build script, and Makefile
• Add publish targets for frontman-protocol, @frontman/bindings, and frontman-core in both lib and root Makefiles

Publish order

These packages must be published to npm before releasing new wrapper versions. The root Makefile now handles this via make publish-deps (or make publish for everything):

1. @frontman-ai/frontman-protocol — no workspace deps
2. @frontman/bindings — no workspace deps
3. @frontman-ai/frontman-core — depends on (1) and (2)
4. Wrappers (nextjs, astro, vite) — depend on (3)

# Publish just the core deps
make publish-deps OTP=<code>

# Publish everything (deps first, then wrappers)
make publish OTP=<code>

Test plan

• All three wrappers (frontman-nextjs, frontman-astro, frontman-vite) build successfully with yarn build:bundle
• Bundle output contains bare import statements for @frontman-ai/frontman-core, @rescript/runtime, sury (not inlined)
• Verify a clean npm install of each published wrapper pulls in frontman-core and its transitive deps
• Smoke-test each framework integration in a sample app
• Run make publish-deps to publish protocol, bindings, and core before releasing wrappers

Closes #419

🤖 Generated with Claude Code

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 10 additional findings in Devin Review.

[devin-ai-integration]

🔴 Astro toolbar build missing noExternal — workspace deps won't be bundled for the browser

The toolbar entry point runs in the browser (platform: 'browser'), so all workspace dependencies must be bundled into the output. The PR moved workspace deps (@frontman-ai/frontman-core, @frontman/bindings, @rescript/runtime, sury, etc.) from devDependencies to dependencies in libs/frontman-astro/package.json:55-60 and simultaneously removed the noExternal list that previously forced bundling. tsup v8 auto-externalizes all packages listed in dependencies for ESM builds, so these deps will now produce bare import statements (e.g. import ... from '@frontman-ai/frontman-core') in the toolbar bundle — which will fail at runtime in the browser where there is no node_modules resolution.

The comment on line 69 even acknowledges the intent: "workspace deps must be bundled, not externalized" — but the config doesn't accomplish this. The old config (libs/frontman-astro/tsup.config.ts at base) had noExternal: sharedNoExternal on the toolbar entry to force bundling. The fix is to add noExternal back for the toolbar build to override tsup's auto-externalization of dependencies.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[BlueHotDog]

The premise here is incorrect. tsup does not auto-externalize packages listed in dependencies. It uses esbuild under the hood and only externalizes what's explicitly in the external array.

The toolbar config at line 76 has external: ['astro', 'astro/toolbar'] — the workspace deps (@frontman-ai/frontman-core, @frontman/bindings, @rescript/runtime, sury, etc.) are intentionally absent from that list, so esbuild will bundle them into dist/toolbar.js. The comment on line 69 even documents this intent: "workspace deps must be bundled, not externalized".

No change needed here.