remix gospel stack
1.0.0
Remix Monorepo de Remix com Turborepo Pipelines, PRISMA, PostgreSQL ou SQLite (LITEFS), Docker implantam para Fly.io, PNPM, Shadcn/UI Tailwindcss.
pnpm create remix@latest --init-script --install --template https://github.com/PhilDL/remix-gospel-stack? Este repositório é opinado:
- Apenas datilografado .
- Somente compatível com o PNPM Package Manager para lidar com os espaços de trabalho Monorepo.
- Usa Turborepo Pipelines + Cache para construir, fiapos, TypeCheck e testar o monorepo.
git clone [email protected]:PhilDL/remix-gospel-stack.git
cd remix-gospel-stack
pnpm add -w @remix-run/dev
pnpm remix initEsta pilha é uma Monorepo Orientada a Remix, alimentada por Turborepo e PNPM Workspaces. Contendo um aplicativo Remix pronto para implantar no Fly.io através da construção de um contêiner do Docker.
Este pacote usa o pnpm como gerente de pacotes de escolha para gerenciar espaços de trabalho. Pode funcionar com yarn e npm se você colocar as definições do espaço de trabalho no arquivo package.json, mas não há garantia.
pasta apps que contêm os aplicativos
remix-app : O aplicativo Remix.run no ESM.remix-vercel : O aplicativo Remix.run, pronto para ser implantado no Vercel.nextjs-app : A Next.js App pasta packages contendo exemplos
ui : Um exemplo de pacote de interface do reacto, alimentado por shadcn/ui. Alguns exemplos de componentes e configuração de shadcn/ui cauda exportada como plug -in e predefinição do Tailwind.database : um invólucro PRISMA pronto para ser usado em outros pacotes ou aplicativos. Faciado com Tsup. Pode ser postgreresql ou sqlite // litefs confiando o que você escolhe durante a instalação.business : um pacote de exemplo usando o database PRISMA como uma dependência e usando um padrão de repositório como exemplo.internal-nobuild : um pacote de exemplo que é puro e sem etapas de construção. O ponto de entrada main do pacote é diretamente src/index.ts . O Remix cuida da compilação com sua própria etapa de construção (com a Esbuild). Esses pacotes também contém teste de unidade com o Vitest. O Remix usa os caminhos tsconfig.json para referência a esse projeto e seus tipos. Eu recomendaria esses tipos de pacotes internos quando você não planeja publicar o pacote. config-packages :
future : {
unstable_optimizeDeps : true ,
v3_fetcherPersist : true ,
v3_lazyRouteDiscovery : true ,
v3_relativeSplatPath : true ,
v3_throwAbortReason : true ,
v3_singleFetch : true ,
v3_routeConfig : true ,
} ,Aviso todos os seguintes comandos devem ser lançados no diretório raiz monorepo
Instalar as dependências.
pnpm installVocê também precisa copiar o exemplo .env.example:
cp .env.example .env
cp .env.example .env.dockerInicie o contêiner PostGresql Docker
pnpm run docker:dbNota: O script NPM será concluído enquanto o Docker configura o contêiner em segundo plano. Verifique se o Docker terminou e seu contêiner está em execução antes de prosseguir.
Gerar esquema de prisma
pnpm run generateExecute a migração do prisma para o banco de dados
pnpm run db:migrate:deploy Execute a primeira construção (com dependências através da opção ...
pnpm run build --filter=@remix-gospel-stack/remix-app... Executar pnpm run build construirá tudo, incluindo o aplicativo NextJS.
Execute o servidor de dev remix
pnpm run dev --filter=@remix-gospel-stack/remix-appPara alternar entre PostgreSQL e SQLite (LITEFS), há um gerador turbo que você pode usar na raiz do repositório.
pnpm turbo gen scaffold-database Em seguida, siga os prompts. Tenha cuidado, porém, as migrações do PRISMA estão vinculadas a um banco de dados específico, portanto, você precisará excluir a pasta migrations .
NOTA: Você precisará executar
pnpm i --fix-lockfilenovamente após a troca para SQLite (LITEFS) que requerem outro pacote (LITEFS-JS). Você provavelmente também terá que executarpnpm run setupnovamente para gerar a primeira migração.
turbo gen workspace --name @remix-gospel-stack/foobarbaz --type package --copyEm seguida, siga os prompts
Verifique o arquivo turbo.json para ver os pipelines disponíveis.
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 . Qualquer pacote ou aplicativo se estenderá dessas configurações. Aviso todos os seguintes comandos devem ser lançados no diretório raiz monorepo
Antes de sua primeira implantação, você precisará fazer algumas coisas:
Primeiro escurece a mosca cli
fly auth signupCrie dois aplicativos em Fly, um para estadiamento e outro para produção:
fly apps create remix-gospel-stack
fly apps create remix-gospel-stack-stagingNota: Depois de criar um aplicativo com sucesso, verifique o arquivo
fly.tomlpara garantir que a chaveappseja o nome do aplicativo de produção que você criou. Essa pilha anexa automaticamente um sufixo exclusivo no Init, que pode não corresponder aos aplicativos que você criou em Fly. Você provavelmente verá 404 erros em seus registros de ações do GitHub se tiver essa incompatibilidade.
Inicialize o git.
git initCrie um novo repositório do GitHub e adicione -o como controle remoto para o seu projeto. Não empurre seu aplicativo ainda!
git remote add origin < ORIGIN_URL > Adicione um FLY_API_TOKEN ao seu repositório do GitHub. Para fazer isso, vá para as configurações do usuário em Fly e crie um novo token e adicione -o aos seus segredos repositórios com o nome FLY_API_TOKEN .
Crie um banco de dados para seus ambientes de preparação e produção:
Criação de banco de dados:
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: Você receberá o mesmo aviso pelo mesmo motivo ao anexar o banco de dados de estadiamento que você fez na
fly set secretacima. Sem problemas. Prossiga!
O Fly cuidará de definir o segredo DATABASE_URL .
Aviso todos os seguintes comandos devem ser lançados no diretório raiz monorepo
Antes de sua primeira implantação, você precisará fazer algumas coisas:
Primeiro escurece a mosca cli
fly auth signupCrie dois aplicativos em Fly, um para estadiamento e outro para produção:
fly apps create remix-gospel-stack
fly apps create remix-gospel-stack-stagingNota: Depois de criar um aplicativo com sucesso, verifique o arquivo
fly.tomlpara garantir que a chaveappseja o nome do aplicativo de produção que você criou. Essa pilha anexa automaticamente um sufixo exclusivo no Init, que pode não corresponder aos aplicativos que você criou em Fly. Você provavelmente verá 404 erros em seus registros de ações do GitHub se tiver essa incompatibilidade.
Inicialize o git.
git initCrie um novo repositório do GitHub e adicione -o como controle remoto para o seu projeto. Não empurre seu aplicativo ainda!
git remote add origin < ORIGIN_URL > Adicione um FLY_API_TOKEN ao seu repositório do GitHub. Para fazer isso, vá para as configurações do usuário em Fly e crie um novo token e adicione -o aos seus segredos repositórios com o nome FLY_API_TOKEN .
Crie um volume persistente para o banco de dados SQLite para seus ambientes de estadiamento e produção. Execute o seguinte (sinta -se à vontade para alterar o tamanho do GB com base nas suas necessidades e na região de sua escolha (https://fly.io/docs/reference/regions/). Se você alterar a região, altere também o primário_region em 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-stagingEm seguida, anexe os volumes aos aplicativos:
fly consul attach --app remix-gospel-stack
fly consul attach --app remix-gospel-stack-staging Agora que tudo está configurado, você pode se comprometer e empurrar suas alterações no seu repositório. Cada comprometimento com sua filial main desencadeará uma implantação para o seu ambiente de produção e todo comprometimento com sua filial dev desencadeará uma implantação para o seu ambiente de estadiamento.
Se você tiver algum problema de implantação para voar, verifique se você seguiu todas as etapas acima e, se tiver, poste tantos detalhes sobre sua implantação (incluindo o nome do seu aplicativo) na comunidade de suporte à mosca. Eles normalmente são bastante responsivos por lá e, esperançosamente, podem ajudar a resolver qualquer um dos seus problemas e perguntas de implantação.
Depois de ter seu site e banco de dados em execução em uma única região, você pode adicionar mais regiões seguindo os documentos de escala e multi-region da Fly.
Certifique -se de definir uma variável de ambiente PRIMARY_REGION para o seu aplicativo. Você pode usar [env] Config no fly.toml para defini -lo na região que deseja usar como região principal para o seu aplicativo e banco de dados.
Instale a extensão do navegador ModHeader (ou algo semelhante) e use-o para carregar seu aplicativo com o conjunto de fly-prefer-region do cabeçalho do nome do nome da região que você gostaria de testar.
Você pode verificar o cabeçalho x-fly-region na resposta para saber qual região sua solicitação foi tratada.
Utilizamos ações do GitHub para integração e implantação contínuas. Qualquer coisa que entrar na filial main será implantada na produção após a execução de testes/construção/etc. Qualquer coisa na filial dev será implantada para encenação.
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/DockerfileSaiba mais sobre o poder do turborepo:
Se você achou o modelo útil, considere dar -lhe uma estrela. Te agradece!
Não sou especialista em Monorepo, Docker ou CI. A configuração proposta aqui é uma das muitas e provavelmente pode ser melhorada 10x, mas estou aprendendo sozinho ao longo do caminho; portanto, se você vir alguma melhoria possível, envie um PR. Agradeço muito!
