create-avocado-site 0.11.1 → 0.11.3

package/dist/templates/common.js

@@ -172,12 +172,45 @@ export function envExample(config) {
 # service to start — this must name this app's own origin, not port 4200.
 ORCHESTRATOR_URL=http://localhost:${config.sitePort}/api/avocado
 
-# Where the editor is served from. Named twice on every request — CORS on the
-# editor API and \`frame-ancestors\` on the preview — and \`withAvocado\` derives
-# both from this one variable. Get it wrong and the site reads as offline while
-# the preview stays a blank rectangle, neither of which mentions a port.
+# Where the editor is served from. Named three times on every request — CORS on
+# the editor API, \`frame-ancestors\` on the preview, and \`corsOrigins\` on the
+# orchestrator route you mount — and \`withAvocado\` derives the first two from
+# this one variable. Get it wrong and the site reads as offline while the
+# preview stays a blank rectangle, neither of which mentions a port.
+#
+# The third is yours to pass. \`createOrchestrator\` with \`corsOrigins\` unset
+# sends no CORS headers under NODE_ENV=production — the right default for a
+# route nobody has told where its editor is, and the reason a production editor
+# can show "Cannot reach the orchestrator" while every route it names answers
+# 200 to curl. Pass it:
+#
+#   corsOrigins: process.env.EDITOR_CORS_ORIGINS?.split(",")
+#     .map((o) => o.trim()).filter(Boolean),
 EDITOR_CORS_ORIGINS=http://localhost:${config.editorPort}
 
+# The same origin again, for the half that reads a different name. The
+# allowlist deciding which origin may drive inline edits over postMessage, and
+# which may be trusted when it arrives in a URL, reads only this and
+# AVOCADO_EDITOR_ORIGINS — never EDITOR_CORS_ORIGINS. Unset in production, the
+# SDK warns on the first editor API request. Set both to the same origin.
+NEXT_PUBLIC_EDITOR_ORIGIN=http://localhost:${config.editorPort}
+
+# Which loopback origins the orchestrator may fetch server-side.
+#
+# In the standalone and Docker deployments this is the orchestrator's CORS
+# allowlist, which is what the deployment docs describe. In library mode CORS
+# comes from \`corsOrigins\` on the route above, so here the variable has exactly
+# one remaining job: \`publish/diff\` fetches the site's published pages from
+# \`siteOrigin\`, and a private address is refused under NODE_ENV=production
+# unless it is listed here. That check is right — an unchecked loopback value
+# would turn the orchestrator into a proxy onto its own host — but with nothing
+# listed, the production Publish panel answers
+# \`400 siteOrigin is not an allowed URL\` for this site's own origin.
+#
+# On a real deployment the site origin is public and passes without this. It is
+# here because \`npm run build && npm start\` on your own machine is not.
+ORCHESTRATOR_CORS_ORIGINS=http://localhost:${config.sitePort}
+
 # Any long random string; this one was generated for you. Without it draft mode
 # does not work, and the editor quietly renders the published page instead of
 # your edits.

package/dist/templates/demo-app.js

@@ -174,6 +174,39 @@ ORCHESTRATOR_URL=http://localhost:${config.sitePort}/api/avocado
 # mentions a port, CORS, or CSP.
 EDITOR_CORS_ORIGINS=http://localhost:${config.editorPort}
 
+# The same origin again, for the half that reads a different name.
+#
+# Three things need to know where the editor lives and they do not share a
+# variable. EDITOR_CORS_ORIGINS above feeds CORS on /api/editor/* and
+# \`frame-ancestors\` on the preview, and the orchestrator route reads it for
+# its own CORS. This one feeds the allowlist that decides which origin may
+# drive inline edits over postMessage and which may be trusted from a URL —
+# a different question, asked by different code, which reads only this name
+# and AVOCADO_EDITOR_ORIGINS.
+#
+# Until this line existed the scaffold wrote the first and not the second, so
+# every generated project warned about its own generated config on every
+# production boot — and the variable the warning named was not the one that
+# fixed the symptom people were chasing. Set both to the same origin; add
+# AVOCADO_EDITOR_ORIGINS only if you run more than one editor deployment.
+NEXT_PUBLIC_EDITOR_ORIGIN=http://localhost:${config.editorPort}
+
+# Which loopback origins the orchestrator may fetch server-side.
+#
+# In the standalone and Docker deployments this is the orchestrator's CORS
+# allowlist, which is what the deployment docs describe. In library mode CORS
+# comes from \`corsOrigins\` on the route above, so here the variable has exactly
+# one remaining job: \`publish/diff\` fetches the site's published pages from
+# \`siteOrigin\`, and a private address is refused under NODE_ENV=production
+# unless it is listed here. That check is right — an unchecked loopback value
+# would turn the orchestrator into a proxy onto its own host — but with nothing
+# listed, the production Publish panel answers
+# \`400 siteOrigin is not an allowed URL\` for this site's own origin.
+#
+# On a real deployment the site origin is public and passes without this. It is
+# here because \`npm run build && npm start\` on your own machine is not.
+ORCHESTRATOR_CORS_ORIGINS=http://localhost:${config.sitePort}
+
 # This site's public origin. It is the only thing a page cannot work out from
 # its own content, and three tags need it: <link rel="canonical">, og:url, and
 # an og:image resolved to an absolute URL — a relative one is legal in the
@@ -427,6 +460,21 @@ const handler = createOrchestrator({
     writeOnPublish: true,
   }),
   previewUrl: "http://localhost:${config.sitePort}",
+  // Where the editor lives, so this route may answer it.
+  //
+  // Unset means "reflect the caller's origin in development, send no CORS
+  // headers in production", which is the right default for a route nobody has
+  // told where its editor is. It is also the shape of a defect two clean-room
+  // runs found: in production every route here answered 200 to curl and the
+  // editor showed "Cannot reach the orchestrator", because a response with no
+  // \`access-control-allow-origin\` is one the browser fetches and discards.
+  //
+  // This is the same variable the SDK reads for CORS on /api/editor/* and for
+  // \`frame-ancestors\` on the preview, so the three places that must agree
+  // about the editor's origin are set from one line in .env.local.
+  corsOrigins: process.env.EDITOR_CORS_ORIGINS?.split(",")
+    .map((origin) => origin.trim())
+    .filter(Boolean),
 })
 
 export const GET = handler

package/dist/versions.d.ts

@@ -17,7 +17,7 @@
  * `@avocadostudio-ai/orchestrator-core`, already pinned there; naming it again
  * here is how a project ends up with two.
  */
-export declare const AVOCADO = "0.11.1";
+export declare const AVOCADO = "0.11.3";
 /**
  * Next 15.5.15 rather than 16, because that is the version every example app
  * and the demo site in this repository build and test against. The SDK

package/dist/versions.js

@@ -17,7 +17,7 @@
  * `@avocadostudio-ai/orchestrator-core`, already pinned there; naming it again
  * here is how a project ends up with two.
  */
-export const AVOCADO = "0.11.1";
+export const AVOCADO = "0.11.3";
 /**
  * Next 15.5.15 rather than 16, because that is the version every example app
  * and the demo site in this repository build and test against. The SDK

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-avocado-site",
-  "version": "0.11.1",
+  "version": "0.11.3",
   "description": "Bootstrap a runnable Avocado Studio demo site, or wire Avocado into an existing Next.js project",
   "type": "module",
   "bin": {
@@ -34,8 +34,8 @@
     "@types/node": "^22.13.10",
     "tsx": "^4.19.0",
     "typescript": "^5.7.3",
-    "@avocadostudio-ai/site-sdk": "0.11.1",
-    "@avocadostudio-ai/shared": "0.11.1"
+    "@avocadostudio-ai/site-sdk": "0.11.3",
+    "@avocadostudio-ai/shared": "0.11.3"
   },
   "license": "Apache-2.0",
   "homepage": "https://docs.avocadostudio.dev",