remix gospel stack

Remix -Gospel -Stack mit Turborepo

Remix TypeScript Monorepo mit Turborepo -Pipelines, Prisma, PostgreSQL oder SQLite (LiteFs), Docker Deploy to fly.io, PNPM, Shadcn/UI Tailwindcss.

QuickStart (empfohlen)

pnpm create remix@latest --init-script --install --template https://github.com/PhilDL/remix-gospel-stack

? Dieses Repository ist Meinungen:

• Nur Typenkript .
• Nur mit dem PNPM -Paketmanager kompatibel, um Monorepo -Arbeitsbereiche zu verarbeiten.
• Verwendet Turborepo -Pipelines + Cache, um den Monorepo zu erstellen, Lint, typecheck und zu testen.

(Alternative) Klonende des Repositorys

git clone [email protected]:PhilDL/remix-gospel-stack.git
cd remix-gospel-stack
pnpm add -w @remix-run/dev
pnpm remix init

Was ist im Stapel

Dieser Stapel ist ein remixorientierter Monorepo, der von Turborepo- und PNPM -Arbeitsbereichen angetrieben wird. Enthält eine resory-Deploy-Remix-App in Fly.io über den Aufbau eines Docker-Containers.

Dieses Paket verwendet pnpm als Paketmanager der Wahl, um Arbeitsbereiche zu verwalten. Es kann mit yarn und npm funktionieren, wenn Sie die Arbeitsbereichdefinitionen in die Datei package.json einfügen, es gibt jedoch keine Garantie.

Monorepo -Architektur von Turborepo- und PNPM -Arbeitsbereichen angetrieben:

• apps -Ordner mit den Anwendungen

  • remix-app : Die App remix.run in ESM.
  • remix-vercel : Die App remix.run, bereit für die Bereitstellung auf Vercel.
  • nextjs-app : Eine Next.js-App

• packages mit Beispielen enthalten

  • ui : Ein React UI -Paketbeispiel von Shadcn/UI. Einige Beispielkomponenten und Shadcn/UI -Tailwind -Konfiguration wurden als Rückenwind -Plugin und voreingestellter Exportion exportiert.
  • database : Ein Prisma -Wrapper, der in anderen Paketen oder Apps verwendet werden kann. Mit TSUP gebündelt. Kann postgresql oder sqlite // litefs abhängig von dem sein, was Sie während der Installation auswählen.
  • business : Ein Beispielpaket, das die Prisma database als Abhängigkeit und ein Repository -Muster wie Beispiel verwendet.
  • internal-nobuild : Ein Beispielpaket mit reinem Typenkript ohne Build-Schritte. Der main für das Paket ist direkt src/index.ts . Remix kümmert sich um das Kompilieren mit einem eigenen Build -Schritt (mit Esbuild). Diese Pakete enthält auch einen Unit -Test mit Vitest. Remix verwendet tsconfig.json -Pfade, um sich auf dieses Projekt und seine Typen zu beziehen. Ich würde diese Art von internen Paketen empfehlen, wenn Sie nicht planen, das Paket zu veröffentlichen.

• config-packages :

  • Eslint -Pakete mit unterschiedlichen voreingestellten Konfigurationen.
  • TS -Konfigurationen, auch mit unterschiedlichen Voreinstellungen.
  • Rückenwindkonfigurationen.

Alle zukünftigen Remix -Flags aktiviert:

 future : {
  unstable_optimizeDeps : true ,
  v3_fetcherPersist : true ,
  v3_lazyRouteDiscovery : true ,
  v3_relativeSplatPath : true ,
  v3_throwAbortReason : true ,
  v3_singleFetch : true ,
  v3_routeConfig : true ,
} ,

Was noch?

• Remix App Multi-Region Fly App-Bereitstellung mit Docker
• Die Datenbank ist in 2 Geschmacksrichtungen erhältlich, die Sie bei der Installation auswählen:
  • Multi-Region-Fliegenpostgresql-Cluster
  • Litefs - verteiltes SQLite
• Remix App HealthCheck Endpoint für Fly Backups Region Fallbacks
• GitHub -Aktionen für die Bereitstellung der Remix -App für die Produktion und Staging -Umgebungen.
• End-to-End-Test mit Dramatikern in der Remix-App
• Unit -Tests mit Vitest- und Testbibliothek in den verschiedenen Paketen.
• Code -Formatierung mit schöneren
• Statische Typen mit TypeScript

Warnung alle folgenden Befehle sollten aus dem Monorepo -Root -Verzeichnis gestartet werden

Entwicklung

• Installieren Sie die Abhängigkeiten.

  pnpm install

  Sie müssen auch das Beispiel kopieren .Env.example:

  cp .env.example .env
  cp .env.example .env.docker

• Starten Sie den Postgresql Docker -Container

  pnpm run docker:db

  HINWEIS: Das NPM -Skript wird abgeschlossen, während Docker den Container im Hintergrund einrichtet. Stellen Sie sicher, dass Docker fertig ist und Ihr Container vor dem Fortfahren ausgeführt wird.

• Erzeugen Sie Prisma -Schema

  pnpm run generate

• Führen Sie die Prisma -Migration in die Datenbank durch

  pnpm run db:migrate:deploy

• Führen Sie den ersten Build aus (mit Abhängigkeiten über die ... Option ...)

  pnpm run build --filter=@remix-gospel-stack/remix-app...

  Einfach pnpm run build läuft alles, einschließlich der nächsten Js -App.

• Führen Sie den Remix Dev Server aus

  pnpm run dev --filter=@remix-gospel-stack/remix-app

Wechseln Sie zwischen PostgreSQL und SQLite (Litefs)

• Um zwischen PostgreSQL und SQLite (LiteFs) zu wechseln, können Sie einen Turbogenerator vom Stammwurzel des Repositorys verwenden.

  pnpm turbo gen scaffold-database

  Folgen Sie dann den Eingabeaufforderungen. Seien Sie jedoch vorsichtig, Prisma -Migrationen sind mit einer bestimmten Datenbank verknüpft, sodass Sie den migrations löschen müssen.

  Hinweis: Sie müssen pnpm i --fix-lockfile erneut ausführen, nachdem Sie zu SQLite (LiteFs) gewechselt sind, für das ein anderes Paket (Litefs-JS) erforderlich ist. Sie müssen wahrscheinlich auch pnpm run setup erneut ausführen, um die erste Migration zu generieren.

Pakete erstellen

Internes Paket

turbo gen workspace --name @remix-gospel-stack/foobarbaz --type package --copy

Folgen Sie dann den Eingaben

Tests, tazipienübergreifende Pakete installieren ...

Überprüfen Sie die Datei turbo.json , um die verfügbaren Pipelines anzuzeigen.

• Führen Sie die Cypress -Tests und Dev durch

  pnpm run test:e2e:dev --filter=@remix-gospel-stack/remix-app

• FININT ALLES

  pnpm run lint

• Typecheck den ganzen monorepo

  pnpm run typecheck

• Testen Sie den gesamten Monorepo

  pnpm run test
  or
  pnpm run test:dev

• Wie installiere ich ein NPM -Paket in der Remix -App?

  pnpm add dayjs --filter @remix-gospel-stack/remix-app

• Optimieren Sie die Tsconfigs, Eslint-Konfigurationen im Ordner config-package . Jedes Paket oder eine App erstreckt sich dann von diesen Konfigurationen.

Bereitstellung auf fly.io - postgresql

Warnung alle folgenden Befehle sollten aus dem Monorepo -Root -Verzeichnis gestartet werden

Vor Ihrer ersten Bereitstellung müssen Sie ein paar Dinge tun:

• Zuerst singup the fly cli

  fly auth signup

• Erstellen Sie zwei Apps bei Fly, eine für die Inszenierung und eine für die Produktion:

  fly apps create remix-gospel-stack
  fly apps create remix-gospel-stack-staging

  Hinweis: Sobald Sie eine App erfolgreich erstellt haben, überprüfen Sie die Datei fly.toml , um sicherzustellen, dass der app Schlüssel der Name der von Ihnen erstellten Produktions-App ist. Dieser Stapel findet automatisch ein eindeutiges Suffix bei Init an, das möglicherweise nicht mit den Apps übereinstimmt, die Sie bei Fly erstellt haben. Sie werden wahrscheinlich 404 Fehler in Ihren GitHub -Aktionen CI -Protokolle sehen, wenn Sie diese Nichtübereinstimmung haben.

• Git initialisieren.

  git init

• Erstellen Sie ein neues Github -Repository und fügen Sie es dann als Fernbedienung für Ihr Projekt hinzu. Schieben Sie Ihre App noch nicht!

  git remote add origin < ORIGIN_URL >

• Fügen Sie Ihrem Github -Repo eine FLY_API_TOKEN hinzu. Gehen Sie dazu bei Fly zu Ihren Benutzereinstellungen und erstellen Sie ein neues Token. Fügen Sie es dann mit dem Namen FLY_API_TOKEN zu Ihren Repo -Geheimnissen hinzu.

• Erstellen Sie eine Datenbank sowohl für Ihre Inszenierungs- als auch für Ihre Produktionsumgebungen:

Datenbankerstellung:

fly postgres create --name remix-gospel-stack-db
fly postgres attach --app remix-gospel-stack remix-gospel-stack-db

fly postgres create --name remix-gospel-stack-staging-db
fly postgres attach --app remix-gospel-stack-staging remix-gospel-stack-staging-db

HINWEIS: Sie erhalten die gleiche Warnung aus dem gleichen Grund, wenn Sie die Staging -Datenbank anhängen, die Sie in der obigen fly set secret -Stufe gemacht haben. Keine Sorge. Fortfahren!

Fly kümmert sich um das Einstellen des für Sie DATABASE_URL -Geheimnisses.

Bereitstellung auf Fly.io - SQLite Litefs

Warnung alle folgenden Befehle sollten aus dem Monorepo -Root -Verzeichnis gestartet werden

Vor Ihrer ersten Bereitstellung müssen Sie ein paar Dinge tun:

• Zuerst singup the fly cli

  fly auth signup

• Erstellen Sie zwei Apps bei Fly, eine für die Inszenierung und eine für die Produktion:

  fly apps create remix-gospel-stack
  fly apps create remix-gospel-stack-staging

  Hinweis: Sobald Sie eine App erfolgreich erstellt haben, überprüfen Sie die Datei fly.toml , um sicherzustellen, dass der app Schlüssel der Name der von Ihnen erstellten Produktions-App ist. Dieser Stapel findet automatisch ein eindeutiges Suffix bei Init an, das möglicherweise nicht mit den Apps übereinstimmt, die Sie bei Fly erstellt haben. Sie werden wahrscheinlich 404 Fehler in Ihren GitHub -Aktionen CI -Protokolle sehen, wenn Sie diese Nichtübereinstimmung haben.

• Git initialisieren.

  git init

• Erstellen Sie ein neues Github -Repository und fügen Sie es dann als Fernbedienung für Ihr Projekt hinzu. Schieben Sie Ihre App noch nicht!

  git remote add origin < ORIGIN_URL >

• Fügen Sie Ihrem Github -Repo eine FLY_API_TOKEN hinzu. Gehen Sie dazu bei Fly zu Ihren Benutzereinstellungen und erstellen Sie ein neues Token. Fügen Sie es dann mit dem Namen FLY_API_TOKEN zu Ihren Repo -Geheimnissen hinzu.

Erstellen Sie ein anhaltendes Volumen für die SQLite -Datenbank sowohl für Ihre Staging- als auch für Ihre Produktionsumgebungen. Führen Sie Folgendes aus (ändern Sie die GB -Größe basierend auf Ihren Anforderungen und der Region Ihrer Wahl (https://fly.io/docs/reference/regions/). Wenn Sie die Region ändern, ändern Sie auch die Primary_region in fly.toml):

fly volumes create data --region cdg --size 1 --app remix-gospel-stack
fly volumes create data --region cdg --size 1 --app remix-gospel-stack-staging

Fügen Sie dann die Volumes an die Apps an:

fly consul attach --app remix-gospel-stack
fly consul attach --app remix-gospel-stack-staging

Starten Sie die Codierung!

Jetzt, da alles eingerichtet ist, können Sie Ihre Änderungen in Ihr Repo festlegen und weitergeben. Jeder Verpflichtung zu Ihrer main wird eine Bereitstellung für Ihre Produktionsumgebung auslösen, und jeder Verpflichtung zu Ihrer dev wird eine Bereitstellung für Ihre Staging -Umgebung auslösen.

Wenn Sie auf Probleme mit dem Einsatz zum Fliegen stoßen, stellen Sie sicher, dass Sie alle oben genannten Schritte befolgt haben. Wenn Sie dies haben, veröffentlichen Sie so viele Details über Ihre Bereitstellung (einschließlich Ihres App -Namens) in der Fly Support -Community. Sie sind dort normalerweise ziemlich reaktionsschnell und können hoffentlich dazu beitragen, Ihre Bereitstellungsprobleme und Fragen zu lösen.

Multi-Region-Bereitstellungen

Sobald Sie Ihre Website und Datenbank in einer einzigen Region ausgeführt haben, können Sie weitere Regionen hinzufügen, indem Sie die Skalierung von Fly und Multi-Region-Postgreensql-Dokumenten verfolgen.

Stellen Sie sicher, dass Sie eine Variable für PRIMARY_REGION -Umgebungsvariable für Ihre App festlegen. Sie können [env] config in the fly.toml verwenden, um dies auf die Region einzustellen, die Sie als Hauptregion für Ihre App und Ihre Datenbank verwenden möchten.

Testen Sie Ihre App in anderen Regionen

Installieren Sie die Modheader-Browser-Erweiterung (oder ähnliches) und laden Sie Ihre App mit dem Header fly-prefer-region auf den regionalen Namen, den Sie testen möchten.

Sie können den x-fly-region Header über die Antwort überprüfen, um zu wissen, in welcher Region Ihre Anfrage bearbeitet wurde.

Github -Aktionen

Wir verwenden GitHub -Aktionen für die kontinuierliche Integration und Bereitstellung. Alles, was in die main kommt, wird nach Ausführung von Tests/Build/usw. für die Produktion eingesetzt. Alles in der dev wird für die Inszenierung eingesetzt.

Erstellen Sie das Docker -Image manuell für die Bereitstellung mit fly.io

• Erstellen Sie ein Docker -Netzwerk

   docker network create app_network
  

• Erstellen Sie das Docker -Bild

  pnpm docker:build:remix-app

• Führen Sie das Docker -Bild aus

  pnpm docker:run:remix-app

• (OptionNal) Wenn Sie manuell für Fly.io einsetzen möchten:

  DOCKER_DEFAULT_PLATFORM=linux/amd64 flyctl deploy --config ./apps/remix-app/fly.toml --dockerfile ./apps/remix-app/Dockerfile

Nützliche Turborepo -Links

Erfahren Sie mehr über die Kraft von Turborepo:

• Pipelines
• Ausschnitt
• Remote Caching (Beta)
• Scoped -Aufgaben
• Konfigurationsoptionen
• CLI -Verwendung

Danke

• Das ESM-Setup ist stark vom Epic-Stack von @kentcdodds inspiriert
• Vielen Dank an @Shadcn für die erstaunliche Komponentenbibliothek.
• Die UI-Integration und einige gute Praktiken wurden schamlos aus dem @juliusmarmared-Projekt ACME-CORP MONOREPO ausgeliehen

Unterstützung

Wenn Sie die Vorlage nützlich gefunden haben, sollten Sie ihm einen Stern geben. Danke!

Haftungsausschluss

Ich bin in keiner Weise ein Experte für Monorepo, Docker oder CI. Das hier vorgeschlagene Setup ist einer von vielen und könnte wahrscheinlich 10x verbessert werden, aber ich lerne alleine auf dem Weg. Wenn Sie also eine mögliche Verbesserung sehen, geben Sie bitte eine PR ein. Ich werde es sehr schätzen!