Skip to content

chore(cms): remove Strapi provider and rollback path - #114

Merged
keshav-epyc merged 1 commit into
mainfrom
chore/remove-strapi
Aug 27, 2026
Merged

keshav-epyc merged 1 commit into
mainfrom
chore/remove-strapi

Conversation

@keshav-epyc

@keshav-epyc keshav-epyc commented Aug 27, 2026 •

Copy link
Copy Markdown
Collaborator

Both staging and production have run on CMS_PROVIDER=payload since the cutover (#111, #112). The Strapi provider was dead code that still shipped in the Worker bundle and still had STRAPI_* secrets pushed on every deploy.

What this removes

  • lib/strapi/{client,types}.ts and lib/cms/strapi-provider.ts
  • The provider switch itself — getCMS() now constructs PayloadProvider unconditionally. getCMSProviderName / CMSProviderName / the CMS_PROVIDER var are gone from lib/cms/config.ts, wrangler.jsonc (all three blocks), both deploy workflows, and .env.example.
  • scripts/cms-parity.ts and the cms:parity package script — it existed to diff the two providers.
  • STRAPI_URL / STRAPI_API_TOKEN / STRAPI_PREVIEW from both workflows' build env and their wrangler secret bulk payloads, and from cloudflare-env.d.ts.

Bugs fixed along the way

The default CMS_PROVIDER in wrangler.jsonc was still "strapi", and getCMSProviderName() fell back to 'strapi' on any unknown value. A fresh checkout with no .env therefore read Strapi in local dev. That failure mode is gone with the variable.

The default PAYLOAD_URL also still pointed at cms.epyc.in — the old Strapi host. Now epyc-payload-cms.epyc.workers.dev, matching what both named environments already override it to.

Kept deliberately

Comments mentioning legacyStrapiId in payload-provider.ts stay — that field exists in Payload and drives sort order for blogs, projects, and gallery. Removing the explanation would make those sort strings look arbitrary.

Verification

  • pnpm exec tsc --noEmit — clean
  • pnpm test — 114/114 pass
  • pnpm exec eslint — 0 errors (6 pre-existing warnings, none in changed files)

No runtime behaviour change: every environment already resolved to PayloadProvider.

Follow-ups after merge (not in this diff)

  1. wrangler secret bulk upserts and never deletes, so the Strapi secrets still sit on both Workers:
    for e in staging production; do for s in STRAPI_URL STRAPI_API_TOKEN STRAPI_PREVIEW; do
      pnpm exec wrangler secret delete $s --env $e; done; done
    
  2. STAGING_STRAPI_* / PRODUCTION_STRAPI_* GitHub Actions secrets are now unreferenced — remove in repo settings.
  3. docs/payload-*.md are left as historical migration records, including a rollback section that no longer applies.

🤖 Generated with Claude Code

Both staging and production have run on CMS_PROVIDER=payload since the
cutover, so the Strapi provider was dead code that still shipped in the
Worker bundle and still had STRAPI_* secrets pushed on every deploy.

Removes lib/strapi/, StrapiProvider, and the provider switch itself —
getCMS() now constructs PayloadProvider unconditionally. The default
CMS_PROVIDER in wrangler.jsonc was still "strapi", so a fresh checkout
with no .env read Strapi in dev; that failure mode is gone with the var.

Also drops the parity script (it compared the two providers) and fixes
the stale default PAYLOAD_URL, which still pointed at the Strapi host.

Comments mentioning legacyStrapiId are kept — that field exists in
Payload and drives sort order.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@xhawk-ai

xhawk-ai Bot commented Aug 27, 2026

Copy link
Copy Markdown

Warning

XHawk review did not run: out of credits

I stopped before reviewing this PR because your workspace has no credits left, so nothing was posted.

Add credits at app.xhawk.ai/billing, then start the review again from XHawk and I will pick up the latest commit.

@keshav-epyc keshav-epyc changed the title Remove Strapi provider and rollback path chore(cms): remove Strapi provider and rollback path Aug 27, 2026
@keshav-epyc
keshav-epyc merged commit e915c19 into main Aug 27, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant