Add broad Elixir ecosystem support

[Marve10s]

Summary

• Adds Elixir as a first-class ecosystem across shared schemas, CLI prompts/flags, Stack Builder state, URL/command generation, MCP config, smoke presets, and docs.
• Adds plain Mix / OTP scaffolds with optional Phoenix and Ecto-specific templates.
• Adds Elixir-focused tests plus release/parity coverage for command generation and multi-select defaults.

Validation

• bun run test:release
• bun run check-types --cwd apps/cli
• bun run typecheck --cwd apps/web
• bun test apps/cli/test/elixir-ecosystem.test.ts
• bun test apps/web/test/elixir-ecosystem.test.ts
• bun test packages/template-generator/test/template-handlers/elixir-base.test.ts

Notes

The branch also contains the prior React Native ecosystem work that this PR was originally opened for; this push adds the Elixir ecosystem work on top.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
better-fullstack-web	Ready	Preview, Comment	May 23, 2026 9:05pm

[chatgpt-codex-connector]

💡 Codex Review

Better-Fullstack/packages/template-generator/templates/frontend/native/base/App.tsx.hbs

Line 58 in 2fca48c

<NavigationContainer linking={linking}>

Honor mobileDeepLinking in React Navigation scaffold

This template always wires deep-linking into navigation (NavigationContainer linking={linking}), so --mobile-deep-linking none cannot actually disable deep-link helpers for react-navigation projects. In practice, native scaffolds still depend on @/lib/deep-linking/expo-linking even when the user explicitly selects none, so generated output no longer reflects the requested stack.

---

Better-Fullstack/apps/cli/src/mcp.ts

Line 403 in 2fca48c

mobileNavigation: (input.mobileNavigation as ProjectConfig["mobileNavigation"]) ?? "expo-router",

Default MCP mobile navigation to none for web-only stacks

The MCP project-config builder now defaults mobileNavigation to expo-router unconditionally, even when no native-* frontend is selected. Because bfs_plan_project/bfs_create_project use this builder directly, web-only TypeScript requests can be persisted with mobile navigation enabled in config despite having no native app, creating config drift and noisy follow-up compatibility adjustments.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Marve10s]

Addressed the Codex review findings in 3b1a753: React Navigation now honors mobileDeepLinking: none without importing/generated deep-link helpers or expo-linking, MCP mobile defaults are now native-only, and the PR workflows now pin Bun to avoid the setup-bun latest fetch failure. Local verification passed with bun run test:release, focused mobile tests, and a real React Navigation/no-deep-link scaffold install + native typecheck.

[Marve10s]

Follow-up after the Playwright failure: f347c9c fixes the shared command default detector so TypeScript builder changes like --backend fastify, --backend convex, and --frontend next no longer collapse to --yes. Added parity coverage for those core TypeScript selections and reran bun run test:release locally.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 47af19477d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Skip React Native frontend check for implicit defaults

This new validation rejects react-native whenever frontend contains a non-native value, but in --yes mode the config is first seeded from TypeScript defaults (tanstack-router) before ecosystem-specific prompting happens, so --yes --ecosystem react-native now fails even though the user did not provide --frontend. The check should only apply when frontend was explicitly provided (or after React Native defaults are normalized), otherwise default React Native scaffolding is blocked.

Useful? React with 👍 / 👎.

[Marve10s]

Closing this duplicate PR so the Elixir ecosystem work is consolidated in #200.