remix gospel stack

Remix gospel pile with turborepo

Remix TypeScript Monorepo avec des pipelines turborepo, prisma, postgresql ou sqlite (litefs), docker déploier sur fly.io, pnpm, shadcn / ui tailwindcss.

QuickStart (recommandé)

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

? Ce référentiel est opinion:

• TypeScript uniquement.
• Compatible uniquement avec PNPM Package Manager pour gérer les espaces de travail MonorePo.
• Utilise TurborePo Pipelines + Cache pour construire, peluche, typcheck et tester le monorepo.

(Alternative) cloner le référentiel

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

Qu'y a-t-il dans la pile

Cette pile est un monorepo orienté vers le remix propulsé par les espaces de travail TurborePo et PNPM. Contenant une application de remix prête à déploier sur fly.io via la construction d'un conteneur Docker.

Ce package utilise pnpm comme gestionnaire de packages de choix pour gérer les espaces de travail. Cela peut fonctionner avec yarn et npm si vous mettez les définitions de l'espace de travail dans le fichier package.json, mais il n'y a aucune garantie.

Architecture monorepo propulsée par TurborePo et PNPM Workspaces:

• Dossier apps contenant les applications

  • remix-app : l'application remix.run dans ESM.
  • remix-vercel : l'application remix.run, prête à être déployée sur Vercel.
  • nextjs-app : une application Next.js

• packages Folder contenant des exemples

  • ui : un exemple de package UI React propulsé par shadcn / ui. Quelques exemples de composants et de configuration de vent arrière shadcn / ui exportés sous forme de plugin et préréglage du vent arrière.
  • database : un wrapper Prisma prêt à être utilisé dans d'autres packages ou applications. Groupé avec TSUP. Peut être PostgreSQL ou SQLite // LiteFS Dépendance de ce que vous choisissez lors de l'installation.
  • business : un exemple de package utilisant la database PRISMA comme dépendance et utilisant un modèle de référentiel comme un exemple.
  • internal-nobuild : un exemple de package pur sans dactylographie sans étapes de construction. Le point d'entrée main du package est directement src/index.ts . Remix s'occupe de la compilation avec sa propre étape de construction (avec Esbuild). Ces packages contiennent également un test unitaire avec Veest. Remix utilise des chemins tsconfig.json pour référence à ce projet et à ses types. Je recommanderais ces types de packages internes lorsque vous ne prévoyez pas de publier le package.

• config-packages :

  • Packages Eslint avec différentes configurations prédéfinies.
  • TS Configs, également avec différents préréglages.
  • Configurations de vent arrière.

Tous les futurs drapeaux de remix activés:

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

Quoi d'autre ?

• Remix App Multi-Region Fly App Deployment avec Docker
• La base de données est disponible en 2 saveurs que vous choisissez à Installer:
  • Grappe de postgresql à mouches multi-régions
  • Litefs - SQLite distribué
• Remix App Healthcheck Point pour les bases de sauvegarde de la région de la région
• Actions GitHub pour déployer l'application Remix sur les environnements de production vers la production et de mise en scène.
• Tests de bout en bout avec le dramaturge dans l'application Remix
• Test unitaire avec bibliothèque Vuest et Testing à l'intérieur des différents packages.
• Formatage de code avec plus joli
• Types statiques avec dactylographie

Avertissement Toutes les commandes suivantes doivent être lancées à partir du répertoire racine Monorepo

Développement

• Installer les dépendances.

  pnpm install

  Vous devez également copier l'exemple .env.example:

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

• Démarrer le conteneur Docker PostgreSQL

  pnpm run docker:db

  Remarque: le script NPM se terminera pendant que Docker configure le conteneur en arrière-plan. Assurez-vous que Docker a terminé et que votre conteneur fonctionne avant de continuer.

• Générer un schéma prisma

  pnpm run generate

• Exécutez la migration PRISMA vers la base de données

  pnpm run db:migrate:deploy

• Exécutez la première version (avec dépendances via l'option ...

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

  L'exécution simplement pnpm run build construira tout, y compris l'application NextJS.

• Exécutez le serveur Dev Remix

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

Commutation entre PostgreSQL et SQLITE (LITEFS)

• Pour basculer entre PostgreSQL et SQLITE (LITEFS), il y a un turbo générateur que vous pouvez utiliser à partir de la racine du référentiel.

  pnpm turbo gen scaffold-database

  Suivez ensuite les invites. Soyez prudent cependant, les migrations PRISMA sont liées à une base de données spécifique, vous devrez donc supprimer le dossier migrations .

  Remarque: vous devrez à nouveau exécuter pnpm i --fix-lockfile après le passage à SQLite (LiteFS) qui nécessite un autre package (LiteFS-JS). Vous devrez probablement également exécuter pnpm run setup pour générer la première migration.

Créer des packages

Colis interne

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

Puis suivez les invites

Tests, typEChecks, peluches, packages d'installation ...

Vérifiez le fichier turbo.json pour voir les pipelines disponibles.

• Exécutez les tests Cypress et Dev

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

• Pelote tout

  pnpm run lint

• Typcheck tout monorepo

  pnpm run typecheck

• Testez l'ensemble du monorepo

  pnpm run test
  or
  pnpm run test:dev

• Comment installer un package NPM dans l'application Remix?

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

• Ajuster les configs TSConfigs, Eslint dans le dossier config-package . Tout package ou application s'étendra ensuite à partir de ces configurations.

Déploiement sur Fly.io - PostgreSQL

Avertissement Toutes les commandes suivantes doivent être lancées à partir du répertoire racine Monorepo

Avant votre premier déploiement, vous devrez faire quelques choses:

• Première singup the Fly Cli

  fly auth signup

• Créez deux applications sur la mouche, une pour la mise en scène et une pour la production:

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

  Remarque: Une fois que vous avez créé avec succès une application, vérifiez le fichier fly.toml pour vous assurer que la clé de app est le nom de l'application de production que vous avez créée. Cette pile ajoute automatiquement un suffixe unique à init qui peut ne pas correspondre aux applications que vous avez créées sur Fly. Vous verrez probablement 404 erreurs dans vos journaux GitHub Actions CI si vous avez ce décalage.

• Initialiser Git.

  git init

• Créez un nouveau référentiel GitHub, puis ajoutez-le comme télécommande pour votre projet. Ne poussez pas encore votre application!

  git remote add origin < ORIGIN_URL >

• Ajoutez un FLY_API_TOKEN à votre dépôt github. Pour ce faire, accédez à vos paramètres utilisateur sur Fly et créez un nouveau jeton, puis ajoutez-le à vos secrets de référentiels avec le nom FLY_API_TOKEN .

• Créez une base de données pour vos environnements de mise en scène et de production:

Création de la base de données:

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

Remarque: vous obtiendrez le même avertissement pour la même raison lors de la connexion de la base de données de mise en scène que vous avez fait dans la fly set secret ci-dessus. Pas de soucis. Procéder!

Fly s'occupera de définir le secret DATABASE_URL pour vous.

Déploiement sur fly.io - sqlite litefs

Avertissement Toutes les commandes suivantes doivent être lancées à partir du répertoire racine Monorepo

Avant votre premier déploiement, vous devrez faire quelques choses:

• Première singup the Fly Cli

  fly auth signup

• Créez deux applications sur la mouche, une pour la mise en scène et une pour la production:

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

  Remarque: Une fois que vous avez créé avec succès une application, vérifiez le fichier fly.toml pour vous assurer que la clé de app est le nom de l'application de production que vous avez créée. Cette pile ajoute automatiquement un suffixe unique à init qui peut ne pas correspondre aux applications que vous avez créées sur Fly. Vous verrez probablement 404 erreurs dans vos journaux GitHub Actions CI si vous avez ce décalage.

• Initialiser Git.

  git init

• Créez un nouveau référentiel GitHub, puis ajoutez-le comme télécommande pour votre projet. Ne poussez pas encore votre application!

  git remote add origin < ORIGIN_URL >

• Ajoutez un FLY_API_TOKEN à votre dépôt github. Pour ce faire, accédez à vos paramètres utilisateur sur Fly et créez un nouveau jeton, puis ajoutez-le à vos secrets de référentiels avec le nom FLY_API_TOKEN .

Créez un volume persistant pour la base de données SQLite pour vos environnements de mise en scène et de production. Exécutez ce qui suit (n'hésitez pas à modifier la taille GB en fonction de vos besoins et de la région de votre choix (https://fly.io/docs/reference/regions/). Si vous modifiez la région, assurez-vous de modifier le primaire_region dans fly.toml également):

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

Puis attachez les volumes aux applications:

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

Commencez à coder!

Maintenant que tout est configuré, vous pouvez vous engager et pousser vos modifications à votre dépôt. Chaque engagement dans votre branche main déclenchera un déploiement dans votre environnement de production, et chaque engagement dans votre succursale dev déclenchera un déploiement dans votre environnement de mise en scène.

Si vous rencontrez des problèmes qui se déploient pour voler, assurez-vous que vous avez suivi toutes les étapes ci-dessus et si vous en avez, publiez autant de détails sur votre déploiement (y compris le nom de votre application) à la communauté de soutien à la mouche. Ils sont normalement assez réactifs là-bas et, espérons-le, peuvent aider à résoudre l'un de vos problèmes et questions de déploiement.

Déploiements multi-régions

Une fois que vous avez votre site et votre base de données en cours d'exécution dans une seule région, vous pouvez ajouter plus de régions en suivant les documents de mise à l'échelle de Fly et Multi-Region PostgreSQL.

Assurez-vous de définir une variable d'environnement PRIMARY_REGION pour votre application. Vous pouvez utiliser [env] Config dans la fly.toml pour le définir dans la région que vous souhaitez utiliser comme région principale pour votre application et votre base de données.

Tester votre application dans d'autres régions

Installez l'extension du navigateur Modheader (ou quelque chose de similaire) et utilisez-le pour charger votre application avec l'en-tête fly-prefer-region sur le nom de la région que vous souhaitez tester.

Vous pouvez vérifier l'en-tête x-fly-region sur la réponse pour savoir dans quelle région votre demande a été traitée.

Actions github

Nous utilisons des actions GitHub pour l'intégration et le déploiement continus. Tout ce qui pénètre dans la branche main sera déployé en production après avoir exécuté des tests / build / etc. Tout dans la succursale dev sera déployé à la mise en scène.

Construisez manuellement l'image docker à déployer avec fly.io

• Créer un réseau Docker

   docker network create app_network
  

• Construisez l'image Docker

  pnpm docker:build:remix-app

• Exécutez l'image docker

  pnpm docker:run:remix-app

• (OptionNal) si vous souhaitez déployer manuellement sur Fly.io:

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

Liens de turborepo utiles

En savoir plus sur la puissance de Turborepo:

• Pipelines
• Mise en cache
• Cache à distance (bêta)
• Tâches de portée
• Options de configuration
• Utilisation de la CLI

Merci

• La configuration ESM est fortement inspirée par la pile épique par @kentcdodds
• Merci à @shadcn pour la bibliothèque de composants incroyable.
• L'intégration de l'interface utilisateur et certaines bonnes pratiques ont été empruntées sans vergogne au projet @juusmarminge acme-corp monorepo

Soutien

Si vous avez trouvé le modèle utile, veuillez envisager de lui donner une étoile. Merci!

Clause de non-responsabilité

Je ne suis en aucun cas un expert de Monorepo, Docker ou CI. La configuration proposée ici est l'une des nombreuses et pourrait probablement être améliorée 10x, mais j'apprends par moi-même en cours de route, donc si vous voyez une amélioration possible, veuillez soumettre un PR. Je l'apprécierai grandement!