[yurynix]

Note

Description

Extends the versions lane so that publishing an app records its actors alongside its frontend assets, backend bundles, entities and agents. A new compileActors step compiles every actor under base44/actors/<Name>/entry.ts into its own Durable Object Worker module via the functions-compiler's single-function bundle(), declares it in the create-version call, and stages its bytes at actors/<name>.mjs. Until now a version described an app with actors as if it had none, so the platform would drop them.

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/version/actors.ts (new) — compileActors() reads every actor, compiles each one separately (concurrency 4), and returns an ActorArtifact per actor with its name, entry, source as written, module bytes, size, sha256 digest and the STATIC_EGRESS_ARTIFACT_MARKER contract. Actors are sorted by name so declared order — and therefore each upload slot — never follows a filesystem walk.
• Compiler input scoping — an actor's bundle sees only the files its entry reaches within its own folder plus base44/shared/**, keyed where the compiler looks; a reach into another actor or a backend function stays unresolved and fails the compile. An entry.js is keyed as entry.ts, since that path is how the compiler recognizes an actor (hence bundle() directly rather than cfwBundleInput, which would flatten a no-import entry to main.ts).
• Failure handling — one actor that fails to compile fails the whole publish at step build, before anything is declared; more than 50 actors is refused up front with InvalidInputError to match the server ceiling. The module is also sanity-checked against do_class_name so a plain Worker is never deployed under an actor's identity.
• core/version/api.ts — declares actors in the create-version body (always sent, [] when the app has none), appends actor upload slots after the asset, site-worker and bundle slots so adding actors moves no existing slot, verifies each signed slot path matches actors/<name>.mjs, and uploads each module with putPresignedBody.
• core/version/schema.ts — adds the ActorArtifact interface and actors to ArtifactSet.
• core/version/functions.ts — exports requireCompilerRuntime (now parameterized so the message reads "Actors…" or "Backend functions…"), describeFailure and sha256 for reuse.
• core/project/target.ts — BuildTarget resolves actorsDir (default actors).
• core/version/artifacts.ts — collects actors during the build step.
• Docs — new "Actors are compiled here too" section in docs/versions.md, updated declare/slot-order description and keywords.
• Tests — new tests/core/version-actors.spec.ts (entry keying, shared-module reach, scope isolation, deterministic digests, set-wide failure, the 50-actor cap) and a new publish suite covering declaration shape, per-actor upload slots, slot ordering alongside bundles, the empty-actors case, compile failure, and the standalone binary refusing an app with actors. TestAPIServer signs actor slots; the with-actors fixture gained a base44/shared/limits.ts import so the shared path is exercised end to end, and the actor publish specs pin DENO_DIR for the npm cache (Windows @deno/loader compatibility).

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 whole lane stays behind the BASE44_VERSIONS_API env gate. Like backend functions, actor compilation needs the external esbuild / @deno/loader runtime packages, so the standalone binary refuses an app with actors with DEPENDENCY_NOT_FOUND at step build rather than silently publishing without them — both the npm-mode and binary-mode specs assert nothing is declared in that case.

---

_{🤖 Generated by Claude | 2026-10-19 06:48 UTC | 9dd49bd}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.1.32-pr.665.9dd49bd

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.32-pr.665.9dd49bd"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.1.32-pr.665.9dd49bd"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.1.32-pr.665.9dd49bd
• 🔗 View this commit on GitHub

---

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

[carmelc]

One thing I did not understand is how is the cli supposed to work in a fullstack app given that it looks for the backend functions in the base44/functions folder

[yurynix]

Backend functions can exist also on fullstack app 🙃