phildl/remix-gospel-stack

Remix monorepo template with pnpm, TypeScript and Turborepo. The remix app deploys to fly.io or build to Docker image. Example packages for Database with Prisma, UI, and internal TypeScript packages.

Remix Gospel stack with Turborepo

Remix TypeScript monorepo with Turborepo pipelines, Prisma, PostgreSQL OR SQLite (Litefs), Docker deploy to Fly.io, pnpm, shadcn/ui TailwindCSS.

Quickstart (recommended)

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

💽 This repository is opiniated:

• TypeScript only.
• Only compatible with pnpm package manager to handle monorepo workspaces.
• Uses turborepo pipelines + cache to build, lint, typecheck, and test the monorepo.

(Alternative) Cloning the repository

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

What's in the stack

This stack is a Remix oriented Monorepo powered by turborepo and pnpm workspaces. Containing a ready-to-deploy Remix App on fly.io via the building of a Docker container.

This Package uses pnpm as the package manager of choice to manage workspaces. It may work with yarn and npm if you put the workspace definitions in the package.json file but there is no guarantee.

Monorepo architecture powered by Turborepo and pnpm workspaces:

• apps Folder containing the applications

  • remix-app: the Remix.run app in ESM.
  • remix-vercel: the Remix.run app, ready to be deployed on Vercel.
  • nextjs-app: a Next.js app

• packages Folder containing examples

  • ui: a React UI package example powered by shadcn/ui. Some example components and shadcn/ui Tailwind config exported as Tailwind plugin and preset.
  • database: a Prisma wrapper ready to be used in other packages, or apps. Bundled with tsup. Can be PostgreSQL or SQLite // Litefs dependening of what you choose during installation.
  • business: an example package using the Prisma database as a dependency and using a repository pattern like example.
  • internal-nobuild: an example package that is pure TypeScript with no build steps. The main entrypoint to the package is directly src/index.ts. Remix takes care of compiling with its own build step (with esbuild). This packages also contains unit test with Vitest. Remix uses tsconfig.json paths to reference to that project and its types. I would recommend these types of internal packages when you don't plan on publishing the package.

• config-packages:

  • Eslint packages with different preset configs.
  • TS Configs, also with different presets.
  • Tailwind configs.

What else ?

• Remix App Multi-region Fly app deployment with Docker
• Database comes in 2 flavors that you choose at install:
  • Multi-region Fly PostgreSQL Cluster
  • Litefs - Distributed SQLite
• Remix App Healthcheck endpoint for Fly backups region fallbacks
• GitHub Actions for deploy the Remix App on merge to production and staging environments.
• End-to-end testing with Playwright in the Remix App
• Unit testing with Vitest and Testing Library inside the different packages.
• Code formatting with Prettier
• Static Types with TypeScript

Warning All the following commands should be launched from the monorepo root directory

Developement

• Install the dependencies.

  pnpm install

  You also have to copy the example .env.example:

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

• Start the postgresql docker container

  pnpm run docker:db

  Note: The npm script will complete while Docker sets up the container in the background. Ensure that Docker has finished and your container is running before proceeding.

• Generate prisma schema

  pnpm run generate

• Run the Prisma migration to the database

  pnpm run db:migrate:deploy

• Run the first build (with dependencies via the ... option)

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

  Running simply pnpm run build will build everything, including the NextJS app.

• Run the Remix dev server

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

Switch between PostgreSQL and SQLite (Litefs)

• To switch between PostgreSQL and SQLite (Litefs), there is a turbo generator you can use from the root of the repository.

  pnpm turbo gen scaffold-database

  Then follow the prompts. Be careful though, prisma migrations are linked to a specific database, so you will have to delete the migrations folder.

  Note: You will have to run pnpm i --fix-lockfile again after switching to SQLite (Litefs) that require another package (litefs-js). You will probably also have to run pnpm run setup again to generate the first migration.

Create packages

Internal package

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

Then follow the prompts

Tests, Typechecks, Lint, Install packages...

Check the turbo.json file to see the available pipelines.

• Run the Cypress tests and Dev

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

• Lint everything

  pnpm run lint

• Typecheck the whole monorepo

  pnpm run typecheck

• Test the whole monorepo

  pnpm run test
  or
  pnpm run test:dev

• How to install an npm package in the Remix app ?

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

• Tweak the tsconfigs, eslint configs in the config-package folder. Any package or app will then extend from these configs.

Deployement on fly.io – PostgreSQL

Warning All the following commands should be launched from the monorepo root directory

Prior to your first deployment, you'll need to do a few things:

• First singup the fly CLI

  fly auth signup

• Create two apps on Fly, one for staging and one for production:

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

  Note: Once you've successfully created an app, double-check the fly.toml file to ensure that the app key is the name of the production app you created. This Stack automatically appends a unique suffix at init which may not match the apps you created on Fly. You will likely see 404 errors in your Github Actions CI logs if you have this mismatch.

• Initialize Git.

  git init

• Create a new GitHub Repository, and then add it as the remote for your project. Do not push your app yet!

  git remote add origin <ORIGIN_URL>

• Add a FLY_API_TOKEN to your GitHub repo. To do this, go to your user settings on Fly and create a new token, then add it to your repo secrets with the name FLY_API_TOKEN.

• Create a database for both your staging and production environments:

Database creation:

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

Note: You'll get the same warning for the same reason when attaching the staging database that you did in the fly set secret step above. No worries. Proceed!

Fly will take care of setting the DATABASE_URL secret for you.

Deployement on fly.io – SQLite Litefs

Warning All the following commands should be launched from the monorepo root directory

Prior to your first deployment, you'll need to do a few things:

• First singup the fly CLI

  fly auth signup

• Create two apps on Fly, one for staging and one for production:

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

  Note: Once you've successfully created an app, double-check the fly.toml file to ensure that the app key is the name of the production app you created. This Stack automatically appends a unique suffix at init which may not match the apps you created on Fly. You will likely see 404 errors in your Github Actions CI logs if you have this mismatch.

• Initialize Git.

  git init

• Create a new GitHub Repository, and then add it as the remote for your project. Do not push your app yet!

  git remote add origin <ORIGIN_URL>

• Add a FLY_API_TOKEN to your GitHub repo. To do this, go to your user settings on Fly and create a new token, then add it to your repo secrets with the name FLY_API_TOKEN.

Create a persistent volume for the sqlite database for both your staging and production environments. Run the following (feel free to change the GB size based on your needs and the region of your choice (https://fly.io/docs/reference/regions/). If you do change the region, make sure you change the primary_region in fly.toml as well):

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

Then attach the volumes to the apps:

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

Start coding!

Now that everything is set up you can commit and push your changes to your repo. Every commit to your main branch will trigger a deployment to your production environment, and every commit to your dev branch will trigger a deployment to your staging environment.

If you run into any issues deploying to Fly, make sure you've followed all of the steps above and if you have, then post as many details about your deployment (including your app name) to the Fly support community. They're normally pretty responsive over there and hopefully can help resolve any of your deployment issues and questions.

Multi-region deploys

Once you have your site and database running in a single region, you can add more regions by following Fly's Scaling and Multi-region PostgreSQL docs.

Make certain to set a PRIMARY_REGION environment variable for your app. You can use [env] config in the fly.toml to set that to the region you want to use as the primary region for both your app and database.

Testing your app in other regions

Install the ModHeader browser extension (or something similar) and use it to load your app with the header fly-prefer-region set to the region name you would like to test.

You can check the x-fly-region header on the response to know which region your request was handled by.

GitHub Actions

We use GitHub Actions for continuous integration and deployment. Anything that gets into the main branch will be deployed to production after running tests/build/etc. Anything in the dev branch will be deployed to staging.

Manually Build The Docker Image to deploy with Fly.io

• Create a docker network

  docker network create app_network
  

• Build the docker image

  pnpm docker:build:remix-app

• Run the docker Image

  pnpm docker:run:remix-app

• (Optionnal) If you want to manually deploy to fly.io:

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

Useful Turborepo Links

Learn more about the power of Turborepo:

• Pipelines
• Caching
• Remote Caching (Beta)
• Scoped Tasks
• Configuration Options
• CLI Usage

Thanks

• The ESM setup is heavily inspired by the epic-stack by @kentcdodds
• Thanks to @shadcn for the amazing component library.
• The UI integration and some good practices were shamelessly borrowed from @juliusmarminge project acme-corp monorepo

Support

If you found the template useful, please consider giving it a Star ⭐. Thanks you!

Disclaimer

I am in no way an expert on Monorepo, Docker or CI. The setup proposed here is one of many and probably could be improved 10x, but I am learning by myself along the way, so if you see any possible improvement please submit a PR. I will appreciate it greatly !

remix-gospel-stack's Issues

tailwindcss missing attribute

It looks incomplete, for example I use w-16, but it doesn't actually work. I went to check the generated tailwind.css file, and there is no w-16 item in it, only w-32 item.

Brand new init failing

A brand new init is failing, looks to be because the eslintrc file was moved.

🚨 Oops, remix.init failed

ENOENT: no such file or directory, open '/Users/benkraus/Code/my-project/.eslintrc.js'
 ERROR  Command failed with exit code 1: create-remix --install --typescript --template https://github.com/PhilDL/remix-gospel-stack

Issue importing from mono repro package in remix mixed client server

Hello everyone,

A few months ago, I encountered a significant issue related to importing code in a mono repository setup, specifically when trying to separate server and client code. At the time, I spent many hours attempting to resolve it without success and eventually set it aside due to frustration.

The core of the problem involved a mix-up between server and client code when importing from a package within a mono repo. This was particularly evident when integrating with a Remix app and attempting to use Kiliman's Remix route package. The goal was to encapsulate routes (like authentication) within their respective packages.

I plan to migrate my packages, currently residing in app/packages of a non-mono repo setup, back to a mono repo next year. However, this importing issue was a major obstacle.

To give more context, I was working with Remix v1.18 at that time, and now we have moved to v2.4. It's possible this issue might have been addressed in the newer version.

I'll post some code samples tomorrow for a clearer illustration. Essentially, we need a mechanism to segregate client and server code within packages, ensuring that imports do not get mixed up.

It might be beneficial to discuss the challenges of using mono repos in Remix apps more broadly. If anyone has encountered and resolved this issue or can suggest workarounds, your insights would be greatly appreciated. Such a discussion could help avoid lengthy configuration and troubleshooting headaches in the future.

Thank you for your assistance!

👋👋👋

Hi Phil, sorry to cold message you like this. I didn't know of another way to get in touch with you. I've started working on a side-project that I plan to open-source. It's an ERP system built with Remix.

I was wondering if you'd be willing to give me some advice. I see you work on both Odoo and Remix, so I figure you're more qualified than anyone.

Thanks either way.

Brad Barbin

How to use path alias in packages?

I want to setup path aliases in packages (import from ~/...) to replace relative imports with aliased imports.

Heer's my configs:

// packages/ui/package.json
{
  "name": "@workspace/ui",
  "type": "module",
  "exports": {
    "./*": "./src/*"
  },
  ...
}

// packages/ui/tsconfig.json
{
  ...,
  "compilerOptions": {
    ...
    "paths": {
      "~/*": [
        "./src/*"
      ],
    },
  }
}

Inside the ui lib package, everything seems fine, no errors whatsoever. But as soon as I import a UI component in my Remix app, I'm getting TS errors:

../../packages/ui/src/components/Button/index.tsx:2:22 - error TS2307: Cannot find module '~/components/Slot' or its corresponding type declarations.

2 import { Slot } from "~/components/Slot";

In my case, Button imports Slot from ~/components/Slot.
If I import from "../Slot"; all is fine again as it doesn't use alias anymore.

Also components that don't import other components or utils don't throw the error.

I am not using tsup.

Am I missing something obvious? Or is this not supported at all? It's probably not a limitation on Remix side, but rather on TS/monorepo.

@prisma/client has no exported member 'PrismaClient'

I got your repo and followed the readme and started it up, then this came. Did you ever get this? I found this online, but I cannot get it to work. I tried adding the .npmrc file for hoisting. I also tried changing the prisma output to node_modules and to a custom location, but that also did not work.

prisma/prisma#13672
https://twitter.com/jaredpalmer/status/1590378768807653378?lang=de
https://turbo.build/repo/docs/handbook/tools/prisma

Thought about easing the configs

I've been working extensively on a project that includes a comprehensive stack with components like a dashboard, admin panel, etc., all built on a mono repository. The setup has been fantastic, but I've identified a potential area for improvement.

In my current workflow, I've encountered several issues, particularly with importing from packages and integrating tools like Storybook in a Remix mono repo setup. These challenges led me to forego the mono repo approach in a new project to streamline the process and avoid configuration complexities.

One idea I've been considering is the possibility of simplifying the configuration process. Specifically, what if we could enhance the existing CLI to centralize the configuration management? Imagine having a master configuration file that governs the settings for all packages and apps. The CLI could then automatically update the respective tsconfig, package.json, and other configuration files. This approach would eliminate repetitive, sometimes nearly identical configurations, reducing the risk of errors and duplications.

Currently, due to unresolved issues with the mono repo setup, I'm developing and refining my packages within a single Remix app under app/packages. The goal is to eventually transition them back to a mono repo structure. A unified configuration system would greatly accelerate this process, making it more efficient and user-friendly.

This is just a thought, and I'm curious to hear if it resonates with others. Perhaps there are already solutions or ideas in this direction that I'm not aware of. Any feedback or suggestions would be greatly appreciated!

Thank you for considering this idea!

Multisite Deploy

How would one go about adding a second remix site and deploying one or both on merge to main?

pnpx is deprecated in favor of `pnpm dlx`

https://stackoverflow.com/a/70266473

questions about dockerfile

1. why do we install openssl? removing it seems ok, but I don't want to remove without knowing.
2. why do we have two pnpm run genrate?

Thanks!

merge all dotenv files to one

First, thanks for the work done in this repo. examples help me a lot, my current monorepo structure is based on this repo.

I recently ran into a problem with packages/database that required to have .env file inside the package. It might be some mistake on my side (I keep using pnpm from the root folder)

I saw in the readme that we should have .env.docker as well.

Am I doing anything wrong?

I would love to find a way to merge them all together. it's weird because I don't know where I should make a change

App freezes after rebuilding

Thanks for making this stack! It's been very helpful when trying to replicate something similar for our repo.

I was running the remix-gospel-stack locally with the pnpm run dev --filter=@remix-gospel-stack/remix-app command, and I noticed that after hot rebuilding the app no longer seemed to work. My initial and subsequent requests to localhost:3000 worked fine, but once I made a change to any of the relevant files and remix rebuilt, further requests to localhost:3000 would never finish loading. Have you seen this on your end? I don't know if it matters, but I did update the @remix-run/dev dependency to ^2.2.0 instead of the previous ^2.0.0.

troubles trying to deploy monorepro with pnpm with dockerfile and dokku

Before using this mono repro I had a working Dockerfile and did a git push dokku master.
That way it would spin up a dokku deployment using the Dockerfile in the root of the project.

Since I switched to pnpm I have not been able to figure out the correct way to deploy, even using gpt4 ( no phun intended ) i tryed to find the correct methodology to deploy my apps.

Even while its a monorepro im still very used to cd to the /apps/myapp folder and do a pnpm dev
The same goes for deployments. I would do a git push dokku master which would initiate the deployment, perhaps that is out of the scope of this repro and my question but deploying isent working at all.

This was my working Dockerfile:
https://gist.github.com/Jarrodsz/22ddc163d1cd8c628e6dd7597b042117

Now the problem even after changing this logical it still fails.
My modified pnpm version would assume to be:
https://gist.github.com/Jarrodsz/13fd50d2eb93914fec560e4364fec650

The problem is i seem to need to copy the package-lock.YAML file from the root of the mono repro, since it is not generated in my /mono_repro/apps/myapp/ folder.

GPT comes up with all kinds of obscure solutions not working.

What would be the correct way to gave an easy workflow for this?
I would like to just do a git push dokku master like im used to.

Is there way to generate the package-lock.yaml in the app folders somehow?
After 2 hours fiddling with the Dockerfile doing 100 deploys to test it and debug it I give up this is cybersome.

Document UI package, build system, components exports, etc...

Document packages/ui setup

Explain tsup config

You don't need to write anything in package.json, it is automatically filled up by the tsup.config.ts

need to document it, that it's auto generated

Originally posted by @chiptus in #98 (comment)

Explain vite setup

Remix is moving to vite, so are we. The vite setup also helps for React libraries, and tailwind setup. Storybook preview.ts file can directly import tailwind.css.

Explain tailwind setup

Tailwind is using shadcn and exporting a preset. These files are built by tsup.

Explain storybook setup

Storybook is setup with vite.

Cannot start new repo.

Unable to start a new project with this template:

Nodejs: v20.10.0

 remix   v2.8.1 💿 Let's build a better website...

   dir   Where should we create your new project?
         my-repo

      ◼  Template: Using https://github.com/PhilDL/remix-gospel-stack...
      ✔  Template copied

   git   Initialize a new git repository?
         No

      ✔  Dependencies installed
      ✔  Dependencies for remix.init script installed

      ◼  Running template's remix.init script...

      ◼  What is the name of the monorepo @org? @my-org
      ◼  Which database do you want to use? (Deployed to Fly.io)       PostgreSQL

      ◼  Preparing monorepo for postgres...

      ▲  Oh no! Template's remix.init script failed

Trying to clone and run the script I get more detail:

Progress: resolved 1789, reused 1669, downloaded 0, added 2109, done
Done in 11.3s
    ◼  What is the name of the monorepo @org? @remix-gospel-stack
    ◼  Which database do you want to use? (Deployed to Fly.io)       PostgreSQL
    ◼  Preparing monorepo for postgres...
Error: 🚨 Oops, remix.init failed

No files match the pattern: /Users/myuser/code-temp/remix-gospel-stack/apps/**/remix.config.js
  at /Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/lib/helpers/glob-async.js:23:23
  at f (/Users/myuser/code-temp/remix-gospel-stack/node_modules/once/once.js:25:25)
  at Glob.<anonymous> (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:148:7)
  at Glob.emit (node:events:514:28)
  at Glob._finish (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:194:8)
  at done (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:179:14)
  at Glob._processSimple2 (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:688:12)
  at /Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:676:10
  at Glob._stat2 (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:772:12)
  at lstatcb_ (/Users/myuser/code-temp/remix-gospel-stack/node_modules/replace-in-file/node_modules/glob/glob.js:764:12)
  at RES (/Users/myuser/code-temp/remix-gospel-stack/node_modules/inflight/inflight.js:31:16)
  at f (/Users/myuser/code-temp/remix-gospel-stack/node_modules/once/once.js:25:25)
  at FSReqCallback.oncomplete (node:fs:199:21)

Litefs instructions, generator incomplete.

The LiteFS build is not working.
So far I found missing litefs.yml in generators, and any instructions about how to troubleshoot things on Fly.
I'm attempting to get it working without any luck which is why I don't have anything else to add to this issue.

Errors in packages not caught by remix app / turbo resulting in non updated ui

Porting all my code to the mono repro I found out a "bug/issue" that is inconvenient at the most.

Say you have an remix app remix-app and import a package named @gospel/ui, and inside this package there is a /src/Component with an error. This error will not appear when running the application like

pnpm run --filter remix-app dev

If however one do a build in the packages/ui and run pnpm build then the error appears.
It caught my attention because i had multiple times i ported components over had some issues with them and my remix app ui would not show any of my components I updated correctly. It will show in the terminal that watchdog saw a modification but those modifications never appear because of in the package there is some error which is a bit confusing and misleading.

Would there be a way around this inconvenient behaviour?

Create index.tsx automatically with a task?

Any suggestions on how to integrate the index export files automatically?

Its should be fairly trival but tried several index generators and they all s*

My idea was to add a generate-index pnpm task so i can automate this and ser incorrect function declarations more easy while porting everything over to my mino repro setup

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (engines:disableMajor)

App not reflecting UI changes directly | needs to do page refresh to see UI changes

Hi,

I was digging on how to set up a monorepo with remix and this appears, thanks for sharing your work men! 😄

I notice that I can not see the UI modifications until I refresh the page. I tryed also running a modified instance of Epic-Stack inside the monorepo and the same happened. This was very strange because I was using the same app outside the monorepo without problems.

I saw that you are using your own server to launch remix (probably due to ESM?) and you are using --manual command during launch. This means that the problem probably comes from there right?

I think it is related with that because I tryed with a plain npx create-remix@latest and it works fine, except if I use the command --manual in the package.json"dev": "remix dev --manual". If I use this the behaveour is more or less the same, you lost Hot reloads and needs to do a complete refresh of the page to see the changes.

Can you confirm if you are suffering the same problem?? (maybe due to latest remix versions?) Thanks 😄

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update all non-major dependencies (@remix-run/css-bundle, @remix-run/dev, @remix-run/eslint-config, @remix-run/express, @remix-run/node, @remix-run/react, @remix-run/serve, @remix-run/server-runtime, @vercel/remix, lucide-react)
• chore(deps): update dependency eslint to v9

Detected dependencies

docker-compose

docker-compose-ci.yml

docker-compose.yml

dockerfile

apps/remix-app/Dockerfile

turbo/generators/templates/Dockerfile.hbs

• flyio/litefs 0.5

github-actions

.github/workflows/deploy.yml

• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• pnpm/action-setup v3.0.0
• actions/setup-node v4
• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• pnpm/action-setup v3.0.0
• actions/setup-node v4
• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• pnpm/action-setup v3.0.0
• actions/setup-node v4
• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• pnpm/action-setup v3.0.0
• actions/setup-node v4
• actions/upload-artifact v4
• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• SebRollen/toml-action v1.2.0
• superfly/flyctl-actions 1.5

npm

apps/nextjs-app/package.json

• next ^14.2.2
• react ^18.2.0
• react-dom ^18.2.0
• @types/node ^20.12.7
• @types/react ^18.2.79
• @types/react-dom ^18.2.25
• typescript ^5.4.5

apps/remix-app/package.json

• @remix-run/express 2.8.1
• @remix-run/node 2.8.1
• @remix-run/react 2.8.1
• address ^2.0.2
• chalk ^5.3.0
• chokidar ^3.5.3
• close-with-grace ^1.2.0
• compression ^1.7.4
• cross-env ^7.0.3
• dotenv ^16.3.1
• execa ^8.0.1
• express ^4.19.2
• get-port ^7.1.0
• morgan ^1.10.0
• react ^18.2.0
• react-dom ^18.2.0
• @faker-js/faker ^8.3.1
• @playwright/test ^1.43.1
• @remix-run/dev 2.8.1
• @remix-run/eslint-config 2.8.1
• @swc/core ^1.5.0
• @swc/helpers ^0.5.10
• @tailwindcss/typography ^0.5.12
• @testing-library/dom ^10.0.0
• @testing-library/jest-dom ^6.2.0
• @testing-library/react ^15.0.4
• @testing-library/user-event ^14.5.2
• @types/compression ^1.7.5
• @types/eslint ^8.56.10
• @types/express ^4.17.21
• @types/fs-extra ^11.0.4
• @types/glob 8.1.0
• @types/morgan ^1.9.9
• @types/node ^20.12.7
• @types/react ^18.2.79
• @types/react-dom ^18.2.25
• @vitejs/plugin-react ^4.2.1
• @vitest/coverage-v8 ^1.5.0
• autoprefixer ^10.4.19
• concurrently ^8.2.2
• esbuild 0.20.2
• eslint 8.57.0
• fs-extra ^11.2.0
• glob ^10.3.12
• happy-dom ^14.0.0
• msw ^2.2.14
• nodemon ^3.1.0
• npm-run-all2 ^6.0.0
• postcss ^8.4.38
• postcss-load-config ^5.0.0
• start-server-and-test ^2.0.3
• tailwindcss ^3.4.3
• tailwindcss-animate ^1.0.7
• ts-node ^10.9.2
• tsx ^4.7.2
• typescript ^5.4.5
• vite ^5.2.10
• vite-tsconfig-paths ^4.3.2
• vitest ^1.5.0

apps/remix-vercel/package.json

• @remix-run/css-bundle 2.8.1
• @remix-run/node 2.8.1
• @remix-run/react 2.8.1
• @remix-run/serve 2.8.1
• @remix-run/server-runtime 2.8.1
• @vercel/analytics ^1.1.1
• @vercel/remix 2.8.1
• isbot ^5.1.4
• react ^18.2.0
• react-dom ^18.2.0
• source-map-support ^0.5.21
• @remix-run/dev 2.8.1
• @remix-run/eslint-config 2.8.1
• @types/react ^18.2.79
• @types/react-dom ^18.2.25
• @types/source-map-support ^0.5.10
• eslint 8.57.0
• postcss ^8.4.38
• tailwindcss ^3.4.3
• tailwindcss-animate ^1.0.7
• typescript ^5.4.5
• vite ^5.2.10
• vite-tsconfig-paths ^4.3.2

config/eslint/package.json

• @remix-run/eslint-config 2.8.1
• @typescript-eslint/eslint-plugin ^7.7.1
• @typescript-eslint/parser ^7.7.1
• eslint-config-next ^14.2.2
• eslint-config-prettier ^9.1.0
• eslint-config-turbo ^1.13.2
• eslint 8.57.0
• eslint-plugin-tailwindcss ^3.15.1
• typescript ^5.4.5

config/tsconfig/package.json

package.json

• @ianvs/prettier-plugin-sort-imports ^4.2.1
• @remix-run/dev 2.8.1
• @turbo/gen ^1.13.2
• @types/glob 8.1.0
• glob ^10.3.12
• json5 ^2.2.3
• magicast ^0.3.4
• prettier ^3.1.1
• prettier-plugin-tailwindcss ^0.5.14
• replace-in-file ^7.1.0
• turbo ^1.13.2
• typescript ^5.4.5
• pnpm 9.0.6

packages/business/package.json

• tiny-invariant ^1.3.3
• @types/node ^20.12.7
• rimraf ^5.0.5
• tsup ^8.0.0
• tsx ^4.7.2
• typescript ^5.4.5

packages/database/package.json

• @prisma/client ^5.13.0
• @types/node ^20.12.7
• dotenv-cli ^7.4.1
• prisma ^5.13.0
• rimraf ^5.0.5
• tsup ^8.0.0
• tsx ^4.7.2
• typescript ^5.4.5

packages/internal-nobuild/package.json

• rimraf ^5.0.5
• tsup ^8.0.0
• typescript ^5.4.5
• vite ^5.2.10
• vite-tsconfig-paths ^4.3.2
• vitest ^1.5.0

packages/ui/package.json

• @radix-ui/react-checkbox ^1.0.4
• @radix-ui/react-slot ^1.0.2
• class-variance-authority ^0.7.0
• clsx ^2.1.1
• lucide-react ^0.372.0
• npm-run-all2 ^6.0.0
• tailwind-merge ^2.3.0
• @remix-run/dev 2.8.1
• @remix-run/node 2.8.1
• @storybook/addon-essentials ^8.0.9
• @storybook/addon-interactions ^8.0.9
• @storybook/addon-links ^8.0.9
• @storybook/addon-onboarding ^8.0.9
• @storybook/blocks ^8.0.9
• @storybook/cli ^8.0.9
• @storybook/react ^8.0.9
• @storybook/react-vite ^8.0.9
• @storybook/test ^8.0.9
• @tailwindcss/typography ^0.5.12
• @types/node ^20.12.7
• @types/react ^18.2.79
• @types/react-dom ^18.2.25
• @vitejs/plugin-react ^4.2.0
• autoprefixer ^10.4.19
• concurrently ^8.2.2
• eslint-plugin-storybook ^0.8.0
• postcss ^8.4.38
• react ^18.2.0
• react-dom ^18.2.0
• storybook ^8.0.9
• tailwindcss ^3.4.3
• tailwindcss-animate ^1.0.7
• tsup ^8.0.0
• typescript ^5.4.5
• vite ^5.2.10
• vite-tsconfig-paths ^4.3.2
• eslint 8.57.0
• @remix-run/dev 2.8.1
• @remix-run/node 2.8.1
• react ^18.2.0
• react-dom ^18.2.0
• tailwindcss ^3.3.2
• tailwindcss-animate ^1.0.6

remix.init/package.json

• execa ^8.0.1
• inquirer ^9.2.6
• parse-github-url ^1.0.2
• toml ^3.0.0
• replace-in-file ^7.0.1
• chalk ^5.3.0

---

• Check this box to trigger a request for Renovate to run again on this repository

remix: Permission denied error

Thanks for putting this together! I'm hitting an issue where the remix cli doesn't have the executable bit set and therefore is causing a "Permission denied error"

remix build

sh: 1: remix: Permission denied

# ls -lah ./node_modules/@remix-run/dev/dist/cli.js
-rw-r--r-- 1 root root 550 Apr 25 16:22 ./node_modules/@remix-run/dev/dist/cli.js

about custom deploy

Hi, PhilDL.

I use this command

pnpm run build --filter=remix-app...

Successfully generated two directories, in remix-app,

One is located in remix-app/build
The other is located in remix-app/public/build.

I bought a vps server of vultr, and installed centos 8 system, and then installed npm, and pm2 tools.

I created a test-web directory under the root directory, and uploaded the index.js under the remix-app/build directory to test-web, and then used pm2 start index.js. Then I tried to access it through the ip address, but I couldn't access it successfully. Is my deployment process correct?

Can I remove remix-app/server.ts?

A core question, what should I do if I don't want to use the remix-app/server.ts method as the backend, but use the api service developed by Golang?

docker-compose can be replaced with `docker compose`

these days compose comes with docker, and can be run with docker compose ...