feat(project): default the site block's two build commands

[ronnyrin]

Note

Description

Gives the site block's two commands schema-level defaults (installCommand → npm install, buildCommand → npm run build) — the conventions base44 create already scaffolds — so a block only has to name what a project does differently. serveCommand and outputDirectory are deliberately left undefaulted: their absence is the signal that there is no frontend to run and nothing built to upload, so base44 dev still runs the backend alone and base44 deploy still skips the site step. site itself stays optional, so "is there a site?" still keys on the block. The practical effect is that a project with a partial site block can now run base44 build and deploy --build instead of being refused, and the deploy flow may offer to build first.

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

• core/project/schema.ts: SiteConfigSchema.buildCommand and installCommand change from .optional() to .default("npm run build") / .default("npm install"), with a comment explaining why serveCommand and outputDirectory are intentionally excluded.
• cli/commands/project/eject.ts: the post-eject install-build-deploy offer now keys on the presence of a site block rather than on both commands being set — that guard went dead once the commands default, and having a block is the whole question, since a backend-only project has nothing to build.
• cli/commands/project/site-build.ts: the "no build command" hint now tells the user to add a site block and notes that buildCommand defaults inside one.
• docs/deployments.md: the site deploy build prompt is now described as firing whenever the project has a site block, since buildCommand defaults inside one.
• CHANGELOG.md: entry under Changed describing the defaults and the deliberate omissions.

Testing

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

Test changes:

• New fixture with-site-defaults (empty "site": {} block plus a package.json build script that records VITE_BASE44_APP_ID).
• tests/core/project.spec.ts: three cases — a partial block keeps its named field and picks up both command defaults, an empty block defaults both commands while leaving serveCommand/outputDirectory undefined, and a project with no site block still has no site at all.
• tests/cli/build.spec.ts: the two "fails when the project has no site.buildCommand" cases are replaced by one asserting build now succeeds via the default command; the no-site-block failure case is kept.
• tests/cli/deploy.spec.ts: guards the deliberate omission — a block with only a serveCommand deploys no site and never reports "Site from".

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

Behaviour does change for projects that already declared a partial site block: they now build and deploy on the defaults instead of being refused, which is why "Breaking change" is checked alongside "New feature" — no config becomes invalid, but an existing block can do more than it used to.

The asymmetry is the point and is worth reviewing on its own terms: defaulting outputDirectory to ./dist would silently turn any site block into an upload of whatever happened to be sitting there (or fail a previously-green deploy after every other resource had already been pushed), and defaulting serveCommand would spawn a dev server for every site block. Commands that exist only to serve or build a site supply their own fallback, where the intent is unambiguous.

---

_{🤖 Generated by Claude | 2026-09-22 10:50 UTC | 619a424}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.1.16-pr.634.619a424

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.16-pr.634.619a424"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.1.16-pr.634.619a424"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.1.16-pr.634.619a424
• 🔗 View this commit on GitHub

---

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

[yurynix]

Best of luck on your quest