2 Commits

Author	SHA1	Message	Date
Bilal Godil	7125a9eff4	feat(hexclave): rename @stackframe/* → @hexclave/* (PR 3) ... Source rename across the monorepo. Every publishable package now ships under its @hexclave/* name natively, no rewrite-at-publish indirection. Workflow + tooling: - Delete scripts/rewrite-packages-to-hexclave.ts (one-shot mirror). - Remove the mirror-publish block from .github/workflows/npm-publish.yaml. The remaining `pnpm publish -r` step publishes @hexclave/* natively. - Flip the auto-bump changeset target from @stackframe/stack to @hexclave/next so 'Update package versions on dev' keeps working. - Delete packages/template/src/internal/deprecation-warning.ts and its imports — @hexclave/* never warns about itself, and after PR 3 no @stackframe/* artifact is ever built from source again. Package renames (publishable): @stackframe/react → @hexclave/react @stackframe/stack → @hexclave/next @stackframe/js → @hexclave/js @stackframe/stack-shared → @hexclave/shared @stackframe/stack-ui → @hexclave/ui @stackframe/stack-sc → @hexclave/sc @stackframe/stack-cli → @hexclave/cli @stackframe/tanstack-start → @hexclave/tanstack-start @stackframe/dashboard-ui-components → @hexclave/dashboard-ui-components Internal monorepo packages (private, never published) also renamed for brand consistency: backend, dashboard, docs, mcp, skills, e2e-tests, example apps, the swift-sdk, the monorepo root, etc. Cost is mechanical; payoff is no stray @stackframe/* names left under apps/, examples/, sdks/. Carve-outs intentionally kept under their legacy names: - @stackframe/emails — virtual module imported by customer-stored email templates; the renderer in apps/backend/src/lib/email-rendering.tsx dual-aliases both names to the same backing module indefinitely. - @stackframe/template — internal codegen source, never published; per docs-mintlify/migration.mdx 'internal packages keep names'. - @stackframe/init-stack — deprecated; now marked private: true so the last published version on npm continues to serve old install commands but the workspace stops publishing it. Backward-compat detection (so projects still on the last @stackframe/* release keep working): - packages/stack-shared/src/config-rendering.ts — CONFIG_IMPORT_PACKAGES table includes both @hexclave/* (canonical, first match wins) and legacy @stackframe/* names. Function renamed detectStackframeImportPackage → detectConfigImportPackage. - apps/dashboard/src/lib/github-config-push.ts — import detection regex now matches both @hexclave/<name> and @stackframe/<name>, hexclave preferred. Versions: every renamed package reset to 1.0.0 in source. The repo's existing 'bump versions before merging to main' flow will move them to 1.0.1 on the first publish run, so the dual-publish 1.0.0 from PR 2 is not overwritten. Other touch-ups discovered during sweep: - Root package.json: 'fern' script filter was @stackframe/docs (legacy typo, never resolved) → @hexclave/docs. - README.md contributor note: @stackframe/XYZ → @hexclave/XYZ. - packages/stack-cli/package.json: register `hexclave` bin alongside the legacy `stack` bin so `npx @hexclave/cli init` works on the natively-published artifact (PR 1481's rewrite script did this at publish time; now it's in source). - packages/template/package-template.json: per-platform names + version flipped to hexclave + 1.0.0 to stay in sync with generated package.json. - docs/package.json (legacy fumadocs folder, otherwise carved out of the brand sweep): workspace deps and name updated minimally so `pnpm install` resolves — content (MDX) intentionally untouched per the PR 2 scoping decision. Carve-out files (skipped entirely by the sweep, intentional history): - docs-mintlify/migration.mdx — teaches the rename, references both. - RENAME-TO-HEXCLAVE.md — planning doc, references both indefinitely. - legacy docs/ folder — content untouched per PR 2 carve-out. generate-sdks regenerated packages/{react,stack,js} from template. pnpm-lock.yaml regenerated. Typecheck green on stack-shared, stack, js, react. Dashboard typecheck has pre-existing 'X is of type unknown' errors that need to be investigated separately (likely a local node_modules build state issue, not source).	2026-05-23 17:41:53 -07:00
Aman Ganapathy	4648fc1899	[Feat] new scripts on migrate/seed/init run for internal (#1421) ... ### Context One script grants free plan to any team which is a customer of the internal project who doesnt have it already. We also want to migrate our users (internal) to the latest version of their products. Needed because some subs on dev right now dont have a plan. And internal isnt using latest version of its own growth plan. ### Describing the Paths we want to Account for 1. Users on production who currently don't have a plan should get free plans, since this script is run with every migrate 2. Users on production should get the latest version of each plan of ours. So a forced migration to latest version of internal project plans 3. No other project's products/product lines should be affected. They will continue to have product versioning 4. 2 should apply to test mode subscriptions as well, on top of stripe subscriptions. All of them should be refreshed 5. Internal project itself should get latest version of its own growth plan 6. If the bulldozer write fails, we should be able to recover on next migration (this should already be handled by init bulldozer script, because it checks if prisma db and bulldozer db are out of sync) 7. if the regenerate or backfill fail, we should be able to recover just by rerunning the script 8. Product version table should not balloon. No table should really balloon ### What I've tested on local 1. Put in 1000 db subscription rows, made them all stale and then ran the regen script. It took about 6 minutes to update all of them, and it was idempotent so rerunning it again did nothing. 2. With proper stripe keys I switched off of test mode on the internal app, granted a product to a new team and updated the product's item list. At this point I checked and the new team had the outdated version of the product. Then I ran the regen script and the new team was moved to latest product version. 3. Tried the above with the internal team's growth plan too and it worked as well. 4. Backfill actually grants free plan ### Deployment strategy in prod Run the backfill and the regen scripts once each after your migrations on the prod db. `pnpm db:backfill-internal-free-plans` will make sure every team has a free plan at least if they dont have an existing plan (and it is idempotent). After that, run `pnpm db:regen-internal-subscriptions-to-latest` which will migrate every user to the latest version of their plan (i.e latest snapshot). This should also be idempotent. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Automated backfill to grant internal free plans to qualifying billing teams. * Regeneration tool to refresh internal subscription snapshots to the latest product versions. * **Chores** * Added CLI commands and package scripts to run backfill and regen jobs. * Database init now runs payment initialization before backfill/regen. * **Tests** * Integration and unit tests added/updated to validate backfill, regeneration, and free-plan idempotency. [](https://app.coderabbit.ai/change-stack/hexclave/stack-auth/pull/1421) <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-05-12 16:05:45 -07:00