[birme]

Summary

Scope correction (2026-08-31): this PR originally shipped an opt-in --backend mypages flag. Per birme's explicit scope update on issue #152, this is now a true replacement: osc web publish <name> <dir> unconditionally publishes via osaas-deploy-manager's /mypages API. There is no flag and no conditional branching — the old direct-MinIO path has been removed.

# the only publish path now
osc web publish mysite ./dist

⚠️ Breaking change

web publish used to provision a dedicated MinIO bucket per site and print an "Origin / Origin Path" block so users could manually chain osc web cdn-create afterwards to front the bucket with a CloudFront distribution / custom domain. That workflow is gone. My Pages uses one shared per-tenant storage instance across all of a tenant's pages, not a bucket-per-site — there is nothing for cdn-create to target. Custom domains/CDN in front of a My Pages site are not yet supported (Eyevinn/osaas-deploy-manager#1409, open/unimplemented). Anyone relying on the old bucket + cdn-create flow needs to hold off upgrading until #1409 ships.

What was verified against source (not guessed)

• packages/cli/src/web/cmd.ts, packages/web/src/{publish,bucket,cdn,mypage,index}.ts read directly in this repo before writing any code.
• The /mypages API contract (request/response shapes, status codes, MAX_PAGE_FILE_SIZE_BYTES = 25 MiB, MAX_UPLOAD_FILES_PER_REQUEST = 500, MAX_PAGE_MANIFEST_FILES = 5000, page-name regex, file-path validation) was verified in the original implementation by reading Eyevinn/osaas-deploy-manager's src/apps/mypage.ts / src/api_mypages.ts on main — unchanged in this correction.
• Confirmed via grep -rn "from.*['\"].*bucket['\"]" / ...publish['\"] across packages/ that nothing outside the deleted files imported publish.ts/bucket.ts, and that web cdn-create (packages/web/src/cdn.ts) has zero code dependency on either — the coupling was workflow-only (see breaking-change note above).

What changed in this correction

• packages/cli/src/web/cmd.ts: removed the --backend <backend> option and the -s, --sync (minio-only) option, and all minio/mypages branching. web publish now always calls publishToMyPages(). The custom-domain/CDN regression note is now printed unconditionally after every successful publish.
• Deleted packages/web/src/publish.ts and packages/web/src/bucket.ts — dead code once the minio branch is gone. No other package or example imports either module after this change (confirmed by grep across packages/).
• Deleted packages/web/src/mime.d.ts — only used by the now-deleted bucket.ts.
• packages/web/src/index.ts: removed the publish export.
• packages/web/examples/publish-website.ts: updated to call publishToMyPages instead of the deleted publish().
• Docs: packages/cli/readme.md and packages/web/README.md now document web publish as directly using My Pages, with the breaking-change/regression note kept prominent.
• Tests: added packages/cli/src/web/cmd.test.ts (5 tests) confirming the --backend option no longer exists on the command and that publish unconditionally calls publishToMyPages, including success, error, and regression-note-printed paths. The 19 existing mypage.ts unit tests are untouched and still pass — they were already testing the correct code path.

Testing

• npx lerna run typecheck — clean (this triggers the dependency build chain first; a bare per-package tsc --noEmit in a fresh clone gives phantom errors because @osaas/client-web's lib/ isn't built yet).
• npx lerna run lint — 0 errors (only pre-existing unrelated no-explicit-any warnings in intercom/cmd.ts and user/util.ts).
• npx lerna run pretty (repo-wide --check) — clean.
• npx lerna run test — all 10 projects pass, 336 tests total (19 in packages/web, all in mypage.test.ts; new + existing packages/cli tests pass).

Lessons

The original PR's implementation of the /mypages API integration (mypage.ts), its retry/error handling, and its 19 unit tests were already correct and needed no changes — only the CLI's invocation model was wrong. When a scope-change correction lands on an existing PR, it's worth explicitly re-verifying which parts of the prior work are still sound (via source/test re-run) rather than re-doing everything from scratch. Separately: nx.json's typecheck: { dependsOn: ["build"] } means lerna run typecheck silently builds every workspace package's lib/ as a side effect — that's why lerna run test afterward can resolve @osaas/client-web's type declarations; running test as the very first command in a fresh clone (skipping typecheck) would fail with TS2307 module-not-found.

Closes #152

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com