ci: sync packages/starter to flat repo on push to main#4
Merged
Conversation
On push to main touching the starter (or core's version), the workflow:
1. Checks out the monorepo + target (emdashCommerce/starter) via STARTER_REPO_TOKEN
2. Mirrors packages/starter/ contents into the target, preserving target's .git
3. Rewrites '@dashcommerce/core: workspace:*' -> '^${CORE_VERSION}' (reads version from packages/core/package.json)
4. Regenerates a fresh standalone bun.lockb
5. Commits as github-actions[bot] and pushes to target's main
Content-mirror rather than git subtree split: linear target history, transforms work without rebase fights, per-file history still lives in the monorepo. Each sync commit links back to the source SHA via a URL trailer for traceability.
Known gap: the monorepo-root Dockerfile + docker-compose.yml don't get mirrored (they're monorepo-shaped). Follow-up to add standalone-equivalent files inside packages/starter/ so the flat repo's 'docker compose up' path still works.
Same root cause as the earlier release workflow fix — Astro 6 requires Node >=22.12.0 but the GitHub runner defaults to 20. Bun's runtime doesn't cover this because the astro CLI has a node shebang and forks the runner's native node. Extend the fix to ci.yml so typecheck + build actually pass on pushes and PRs.
CI was failing with 'Failed to resolve entry for package @dashcommerce/core' because core's dist/ is gitignored and only produced by tsdown. Fresh installs (local first-clone, CI every run) didn't have dist, so starter's astro.config.mjs couldn't load it — astro check and astro build both fell over. Chaining core build into the monorepo root postinstall means: - 'bun install' (local dev, CI, contributor first-clone) auto-produces packages/core/dist before any workspace script runs - downstream consumers installing @dashcommerce/core from npm are unaffected — the monorepo root postinstall only runs when someone installs the monorepo itself Trade-off: install time goes from ~12s to ~33s on a fresh clone. Worth it vs. confusing 'core main entry not found' errors that block every workspace command.
Local bun was 1.0.35 but CI's setup-bun pulls latest (1.3.13). Bun 1.3 migrated from the binary bun.lockb to a text-based bun.lock, and the two versions produce non-interchangeable lockfiles — CI's 'bun install --frozen-lockfile' kept bailing with 'lockfile had changes, but lockfile is frozen'. - Upgraded local bun to 1.3.13 via `bun upgrade` - Regenerated lockfile: bun.lockb (binary, 419KB) is gone, replaced by bun.lock (text, 274KB) — textual diffs from here on - sync-starter.yml: its regen step now removes both bun.lock and bun.lockb so it's robust across the transition
CI failed with 'Patch file found for package emdash which is not present at node_modules/emdash' because patch-package looks for deps at the repo root, but emdash is hoisted under packages/starter/node_modules/emdash in a Bun workspace. Locally the install still limped through because macOS shell treats postinstall's '&&' leniently; Linux-on-CI failed strictly.
The stale patch was also for emdash 0.4 (filename: emdash+0.4.0.patch), which would no longer apply now that we're on emdash 0.5.
Migration:
- Ported the three-hunk patch to emdash 0.5 via 'bun patch emdash@0.5.0':
* dist/astro/middleware.mjs: request.json() -> request.clone().json() x2
* src/emdash-runtime.ts: same .clone() fix x2
* src/astro/routes/api/plugins/[pluginId]/[...path].ts: add Response instanceof passthrough before apiSuccess()
All three are about preserving raw request bodies for downstream consumers (Stripe/GitHub/Slack webhook signature verification).
- patches/emdash+0.4.0.patch deleted; patches/emdash@0.5.0.patch generated.
- package.json: patchedDependencies field (bun-native) replaces patch-package devDep; postinstall is now just the core build.
- bun.lock regenerated.
Verified locally with 'rm -rf **/node_modules && bun install --frozen-lockfile' — the CI-equivalent sequence now passes, and bun run typecheck is green.
Two independent bugs surfaced once CI moved past the earlier install errors: 1. Core couldn't find @emdash-cms/admin kit.tsx and MenusPage.tsx import from @emdash-cms/admin but it was reachable only transitively via packages/starter/node_modules/emdash — not from packages/core. Added @emdash-cms/admin@0.5.0 as a core devDependency so typecheck resolves cleanly, and bumped the emdash devDep to ^0.5.0 to match. 2. Starter lost all typed entry.data access on fresh clones packages/starter/emdash-env.d.ts — which augments the EmDashCollections interface — was gitignored. Emdash only writes the file from astro:server:setup (dev server listening), not astro build or astro check, and CI never runs the dev server. Without the file, every typed access on entry.data collapses to 'unknown' and the starter fails with 31 errors. Committing the generated file and documenting in .gitignore that it must be regenerated locally after schema changes (via 'bun run dev' once). Trade-off: slight duplication with the seed schema; alternative was to orchestrate a background dev server in CI which is much more fragile. Verified locally with the full CI sequence: rm -rf node_modules packages/*/node_modules bun install --frozen-lockfile bun run --filter '*' typecheck Both packages now exit 0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On push to main touching the starter (or core's version), the workflow:
Content-mirror rather than git subtree split: linear target history, transforms work without rebase fights, per-file history still lives in the monorepo. Each sync commit links back to the source SHA via a URL trailer for traceability.
Known gap: the monorepo-root Dockerfile + docker-compose.yml don't get mirrored (they're monorepo-shaped). Follow-up to add standalone-equivalent files inside packages/starter/ so the flat repo's 'docker compose up' path still works.