Remix TypeScript Monorepo con tuberías turborepo, prisma, postgreSQL o sqlite (LITEFS), Docker Deploy para Fly.io, PNPM, SHADCN/UI TAYWINDCSS.
pnpm create remix@latest --init-script --install --template https://github.com/PhilDL/remix-gospel-stack? Este repositorio está opinado:
- Solo mecanografiado .
- Solo compatible con el administrador de paquetes PNPM para manejar los espacios de trabajo de Monorepo.
- Utiliza tuberías turborepo + caché para construir, pelusa, typecheck y probar el monorepo.
git clone [email protected]:PhilDL/remix-gospel-stack.git
cd remix-gospel-stack
pnpm add -w @remix-run/dev
pnpm remix initEsta pila es un monorepo orientado a remix impulsado por espacios de trabajo Turborepo y PNPM. Que contiene una aplicación Remix Ready to Deploy en Fly.io a través de la construcción de un contenedor Docker.
Este paquete utiliza pnpm como el administrador de paquetes de elección para administrar espacios de trabajo. Puede funcionar con yarn y npm si coloca las definiciones del espacio de trabajo en el archivo paquete.json, pero no hay garantía.
Carpeta apps que contiene las aplicaciones
remix-app : la aplicación remix.run en ESM.remix-vercel : la aplicación remix.run, lista para implementarse en Vercel.nextjs-app : una aplicación Next.js carpeta packages que contiene ejemplos
ui : un ejemplo de paquete React UI alimentado por Shadcn/UI. Algunos componentes de ejemplo y configuración de viento de cola ShadCn/UI exportaron como complemento de viento de cola y preajuste.database : un envoltorio prisma listo para ser utilizado en otros paquetes o aplicaciones. Bundido con TSUP. Puede ser postgreSQL o sqlite // litefs que depende de lo que elija durante la instalación.business : un paquete de ejemplo que utiliza la database Prisma como dependencia y utilizando un patrón de repositorio como ejemplo.internal-nobuild : un paquete de ejemplo que es puro TypeScript sin pasos de compilación. El punto de entrada main al paquete es directamente src/index.ts . Remix se encarga de la compilación con su propio paso de construcción (con ESBuild). Estos paquetes también contienen prueba unitaria con Vitest. Remix utiliza rutas tsconfig.json para referencia a ese proyecto y sus tipos. Recomendaría este tipo de paquetes internos cuando no planea publicar el paquete. config-packages :
future : {
unstable_optimizeDeps : true ,
v3_fetcherPersist : true ,
v3_lazyRouteDiscovery : true ,
v3_relativeSplatPath : true ,
v3_throwAbortReason : true ,
v3_singleFetch : true ,
v3_routeConfig : true ,
} ,Advertencia todos los siguientes comandos deben lanzarse desde el directorio raíz de Monorepo
Instale las dependencias.
pnpm installTambién debe copiar el ejemplo .env.example:
cp .env.example .env
cp .env.example .env.dockerInicie el contenedor Docker PostgreSQL
pnpm run docker:dbNota: El script NPM se completará mientras Docker configura el contenedor en segundo plano. Asegúrese de que Docker haya terminado y que su contenedor se esté ejecutando antes de continuar.
Generar el esquema de prisma
pnpm run generateEjecute la migración de prisma a la base de datos
pnpm run db:migrate:deploy Ejecute la primera compilación (con dependencias a través de la opción ... )
pnpm run build --filter=@remix-gospel-stack/remix-app... Ejecutar simplemente pnpm run build construirá todo, incluida la aplicación NextJS.
Ejecute el servidor Remix Dev
pnpm run dev --filter=@remix-gospel-stack/remix-appPara cambiar entre PostgreSQL y SQLite (LITEFS), hay un generador turbo que puede usar desde la raíz del repositorio.
pnpm turbo gen scaffold-database Luego siga las indicaciones. Sin embargo, tenga cuidado, las migraciones de prisma están vinculadas a una base de datos específica, por lo que tendrá que eliminar la carpeta migrations .
Nota: Tendrá que ejecutar
pnpm i --fix-lockfilenuevamente después de cambiar a SQLite (LITEFS) que requieren otro paquete (LITEFS-JS). Probablemente también tendrá que ejecutarpnpm run setupnuevamente para generar la primera migración.
turbo gen workspace --name @remix-gospel-stack/foobarbaz --type package --copyLuego sigue las indicaciones
Consulte el archivo turbo.json para ver las tuberías disponibles.
pnpm run test:e2e:dev --filter=@remix-gospel-stack/remix-apppnpm run lintpnpm run typecheckpnpm run test
or
pnpm run test:devpnpm add dayjs --filter @remix-gospel-stack/remix-appconfig-package . Cualquier paquete o aplicación se extenderá desde estas configuraciones. Advertencia todos los siguientes comandos deben lanzarse desde el directorio raíz de Monorepo
Antes de su primera implementación, deberá hacer algunas cosas:
Primer Singup the Fly Cli
fly auth signupCree dos aplicaciones en Fly, una para la puesta en escena y otra para la producción:
fly apps create remix-gospel-stack
fly apps create remix-gospel-stack-stagingNota: Una vez que haya creado con éxito una aplicación, verifique el archivo
fly.tomlpara asegurarse de que la clave deappsea el nombre de la aplicación de producción que creó. Esta pila agrega automáticamente un sufijo único en Init que puede no coincidir con las aplicaciones que creó en Fly. Es probable que vea 404 errores en sus acciones de GitHub CI si tiene este desajuste.
Inicializar git.
git initCree un nuevo repositorio de GitHub y luego agréguelo como el control remoto para su proyecto. ¡No presione su aplicación todavía!
git remote add origin < ORIGIN_URL > Agregue un FLY_API_TOKEN a su repositorio de GitHub. Para hacer esto, vaya a la configuración de su usuario en Fly y cree un nuevo token, luego agréguelo a sus secretos de repo con el nombre FLY_API_TOKEN .
Cree una base de datos para sus entornos de puesta en escena y producción:
Creación de la base de datos:
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-dbNota: Obtendrá la misma advertencia por la misma razón al adjuntar la base de datos de puesta en escena que hizo en el paso
fly set secret. No hay problema. ¡Proceder!
Fly se encargará de establecer la DATABASE_URL en secreto para usted.
Advertencia todos los siguientes comandos deben lanzarse desde el directorio raíz de Monorepo
Antes de su primera implementación, deberá hacer algunas cosas:
Primer Singup the Fly Cli
fly auth signupCree dos aplicaciones en Fly, una para la puesta en escena y otra para la producción:
fly apps create remix-gospel-stack
fly apps create remix-gospel-stack-stagingNota: Una vez que haya creado con éxito una aplicación, verifique el archivo
fly.tomlpara asegurarse de que la clave deappsea el nombre de la aplicación de producción que creó. Esta pila agrega automáticamente un sufijo único en Init que puede no coincidir con las aplicaciones que creó en Fly. Es probable que vea 404 errores en sus acciones de GitHub CI si tiene este desajuste.
Inicializar git.
git initCree un nuevo repositorio de GitHub y luego agréguelo como el control remoto para su proyecto. ¡No presione su aplicación todavía!
git remote add origin < ORIGIN_URL > Agregue un FLY_API_TOKEN a su repositorio de GitHub. Para hacer esto, vaya a la configuración de su usuario en Fly y cree un nuevo token, luego agréguelo a sus secretos de repo con el nombre FLY_API_TOKEN .
Cree un volumen persistente para la base de datos SQLite tanto para sus entornos de puesta en escena como de producción. Ejecute lo siguiente (no dude en cambiar el tamaño de GB en función de sus necesidades y la región de su elección (https://fly.io/docs/reference/regions/). Si cambia la región, asegúrese de cambiar el primario_region en fly.toml también):
fly volumes create data --region cdg --size 1 --app remix-gospel-stack
fly volumes create data --region cdg --size 1 --app remix-gospel-stack-stagingLuego adjunte los volúmenes a las aplicaciones:
fly consul attach --app remix-gospel-stack
fly consul attach --app remix-gospel-stack-staging Ahora que todo está configurado, puede comprometer y impulsar sus cambios a su repositorio. Cada compromiso con su rama main desencadenará una implementación en su entorno de producción, y cada compromiso con su rama dev desencadenará una implementación en su entorno de puesta en escena.
Si se encuentra con problemas de implementación para volar, asegúrese de seguir todos los pasos anteriores y, si lo ha hecho, publique tantos detalles sobre su implementación (incluido el nombre de su aplicación) a la comunidad de soporte de moscas. Normalmente son bastante receptivos allí y, con suerte, pueden ayudar a resolver cualquiera de sus problemas y preguntas de implementación.
Una vez que tenga su sitio y base de datos ejecutándose en una sola región, puede agregar más regiones siguiendo los documentos de escalado y múltiples regiones de Fly.
Asegúrese de establecer una variable de entorno PRIMARY_REGION para su aplicación. Puede usar la configuración [env] en fly.toml para establecerlo en la región que desea usar como región principal tanto para su aplicación como para su base de datos.
Instale la extensión del navegador ModHeader (o algo similar) y úsela para cargar su aplicación con el fly-prefer-region con la región del encabezado, el nombre de la región que desea probar.
Puede verificar el encabezado x-fly-region en la respuesta para saber qué región fue manejada su solicitud.
Utilizamos acciones de GitHub para la integración e implementación continua. Cualquier cosa que llegue a la rama main se implementará en producción después de ejecutar pruebas/construcción/etc. Cualquier cosa en la rama dev se implementará en puesta en escena.
docker network create app_network
pnpm docker:build:remix-apppnpm docker:run:remix-appDOCKER_DEFAULT_PLATFORM=linux/amd64 flyctl deploy --config ./apps/remix-app/fly.toml --dockerfile ./apps/remix-app/DockerfileObtenga más información sobre el poder de Turborepo:
Si encontró útil la plantilla, considere darle una estrella. ¡Gracias!
De ninguna manera soy un experto en Monorepo, Docker o CI. La configuración propuesta aquí es una de las muchas y probablemente podría mejorarse 10 veces, pero estoy aprendiendo solo en el camino, así que si ve alguna posible mejora, envíe un PR. ¡Lo apreciaré mucho!