@webflow/webflow-cli 2.4.0-next.1 → 2.4.0

package/CHANGELOG.md

@@ -1,5 +1,26 @@
 # @webflow/webflow-cli
 
+## 2.4.0
+
+### Minor Changes
+
+- 5b82244: `webflow cloud init` now scaffolds Astro 7 on stable builds. Both Astro scaffolds — standalone (`--new`) and site-attached (`--site-id`) — resolve to the `v3` branch of their example repo, so `@webflow/webflow-cli@next` is no longer needed to get Astro 7.
+
+  The site-attached scaffold also moves to the current DevLink export contract: `webflow.json` uses the `devlink-export` block writing to `./webflow`, and the layout imports the provider, font tags, and global stylesheet from there. Previously it pointed at the legacy `./devlink` output and imported `_Builtin` modules that current exports no longer emit.
+
+  Existing Astro 5 and Astro 6 projects are unaffected — the CLI keeps detecting and building them, and older CLI installs continue pulling the `v2` scaffold.
+
+- b7037b0: Add support for deploying no-framework static apps (plain HTML/CSS/JS) to Webflow Cloud. A project with a root `index.html` and no `package.json` is auto-detected as `static` and deployed assets-only — no build, no worker — matching cosmic-builder's behavior. An explicit `{ "cloud": { "framework": "static" } }` in `webflow.json` also selects it. Framework projects are unaffected.
+
+### Patch Changes
+
+- 5612b91: Fix Astro 6/7 Webflow Cloud apps serving static assets one mount-path segment too deep. On any non-root mount (including the default `/app`), CSS, JS, favicons, and other static assets 404'd because the deploy copied the already mount-nested `dist/client/<mount>/` build output under the mount path a second time (e.g. HTML referenced `/app/_astro/…` but the asset was served at `/app/app/_astro/…`). The asset copy now strips the exact mount path — for any nesting depth, including multi-segment mounts — so Astro 6/7 assets resolve where the generated HTML references them. Astro 5 and Next.js are unaffected.
+
+  The underlying cause is a since-fixed `@astrojs/cloudflare` bug ([withastro/astro#16276](https://github.com/withastro/astro/issues/16276), fixed in `13.3.1`), so Astro 6 now requires `@astrojs/cloudflare@^13.3.1` and upgrades a declared older `13.x` adapter automatically (with a warning). Astro 7 already ships a fixed `14.x` adapter.
+
+- 266ff5c: Fix `webflow library bundle`/`webflow library share` resolving paths against `process.cwd()` instead of the library's root directory. `dirname(manifestPath)` is now the single source of truth for the library root, so `--manifest` works correctly when invoked from outside the library directory (e.g. a monorepo root): tsconfig path aliases, bundler context, manifest-relative fields (`globals`, `bundleConfig`, `renderer`), type checking, source map package lookups, bundle output, and Module Federation exposes are all resolved relative to the manifest's directory.
+- b055972: Recognize upload-backed deployments.
+
 ## 2.3.0
 
 ### Minor Changes

package/dist/cloud-scaffolds/registry.ts

@@ -23,15 +23,18 @@ import { ScaffoldError } from "./types";
  *   3. Bump every `ref` below from `vN` to `vN+1` in the CLI release that
  *      ships the breaking change.
  *
- * Old `vN` branches stay frozen — we don't backport fixes.
+ * Old `vN` branches stay frozen — we don't backport fixes. Published CLIs pin
+ * the branch name they were built with, so a `vN` branch can never be deleted
+ * or force-pushed once it ships.
  *
- * Exception: the `astro-minimal`/`astro` entries additionally set `betaRef`
- * to a framework-version branch name (`astro7`) rather than the next `vN`.
- * `betaRef` is only used on beta (`@next`) builds — see `isBetaBuild()` and
- * `fetcher.ts` — so `cloud init` keeps scaffolding Astro 6 (`ref: "v2"`) on
- * stable until Astro 7 support lands on the cosmic-builder side (CLD-2148)
- * and the CLI's own E2E coverage (CLD-2216) is green, at which point `betaRef`
- * is promoted to `ref`.
+ * Note that `main` is not just a showcase: the Dashboard scaffold wizard always
+ * serves it. Step 2 above is what keeps the wizard and the CLI in agreement, so
+ * skipping it leaves the two handing out different scaffolds.
+ *
+ * An entry may also set `betaRef` to stage the next contract on the pre-release
+ * channel: it replaces `ref` only on beta (`@next`) builds — see `isBetaBuild()`
+ * and `fetcher.ts` — letting a scaffold move ahead for testers while stable keeps
+ * pulling `ref`. Promote by moving the branch to `ref` and dropping `betaRef`.
  */
 export const FRAMEWORK_REGISTRY: Record<string, FrameworkDefinition> = {
   "astro-minimal": {
@@ -40,8 +43,7 @@ export const FRAMEWORK_REGISTRY: Record<string, FrameworkDefinition> = {
     source: {
       type: "github",
       repo: "Webflow-Examples/hello-world-astro",
-      ref: "v2",
-      betaRef: "astro7",
+      ref: "v3",
     },
   },
   "nextjs-minimal": {
@@ -59,8 +61,7 @@ export const FRAMEWORK_REGISTRY: Record<string, FrameworkDefinition> = {
     source: {
       type: "github",
       repo: "Webflow-Examples/hello-world-astro-devlink",
-      ref: "v2",
-      betaRef: "astro7",
+      ref: "v3",
     },
   },
   nextjs: {