feat(build): add base44 build — site buildCommand with the app id injected

[davidsu]

Note

Description

Adds a new base44 build command that runs the site's configured buildCommand with the linked app's id injected as VITE_BASE44_APP_ID. This makes it possible to produce a production bundle that always carries the correct app id, without developers having to remember to export the env var themselves. The build runner lives in its own module (site-build.ts) so it can be reused by other commands later.

Related Issue

None

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Other (please describe):

Changes Made

• New base44 build command (packages/cli/src/cli/commands/project/build.ts): requires a linked local project, reads the project config, runs the site build, and reports the injected app id in its outro message.
• New runSiteBuild() helper (packages/cli/src/cli/commands/project/site-build.ts): executes the buildCommand via execa (shell, project root as cwd) inside runTask, with VITE_BASE44_APP_ID set to the app id.
• Throws ConfigNotFoundError with a hint to add site.buildCommand when no build command is configured, and ConfigInvalidError when run outside a linked project.
• Registered the command in packages/cli/src/cli/program.ts (before deploy).
• Added packages/cli/tests/cli/build.spec.ts covering: successful build with the app id injected, missing site.buildCommand, a failing build command, and running outside a project.
• Added minimal test fixtures with-buildable-site and with-failing-build.
• CHANGELOG entry under ### Added.

Testing

• I have tested these changes locally
• I have added/updated tests as needed
• All tests pass (npm test)

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have updated docs/ (AGENTS.md) if I made architectural changes

Additional Notes

• The command follows the existing factory pattern (Base44Command + getXCommand()), uses runTask for progress/error reporting, and throws typed core errors rather than calling process.exit — consistent with docs/commands.md and docs/error-handling.md.
• runSiteBuild() takes only Pick<CLIContext, "runTask">, so it is straightforward to call from deploy if the site build should become part of the deploy flow.
• The VITE_BASE44_APP_ID name matches what the scaffolded templates and base44 dev/eject already use.
• The test suite was not executed in this environment, so the "all tests pass" box is left unchecked.

---

_{🤖 Generated by Claude | 2026-08-03 07:42 UTC | 967fb6f}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.1.7-pr.586.967fb6f

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.1.7-pr.586.967fb6f"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.1.7-pr.586.967fb6f"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.1.7-pr.586.967fb6f
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[yardend-wix]

in case of editor app => github clone => base44 build, what is the source of the app id? the user should use the --app-id flag?

[davidsu]

The id comes from base44 link, not a flag. An editor-app clone ships base44/config.jsonc but deliberately no .app.jsonc (the platform git-ignores it), so the first base44 build fails pointing at base44 link; link lists editor-created apps since #577 and writes .app.jsonc, and build resolves the id from there like every project command. --app-id/BASE44_APP_ID intentionally don't work here: they carry an id without a project root, and build requires a linked project — injecting app X's id into app Y's checkout is exactly the mistake that guard blocks. If we ever want --app-id to override in unlinked checkouts, that's a product decision to take deliberately, not a gap.