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.

• 👋 Hi, I’m @PhilDL
• 👀 I love Python, TypeScript, Web dev and ERP Systems
• 🎓 Creating tutorials about Odoo and Python ERP on Coding Dodo
• Author of:
  • @ts-ghost Fully Typed tools-suite to interract with Ghost CMS via CLI or API.
  • Astro starter for Ghost CMS
  • Remix Gospel Stack (monorepo)

remix-gospel-stack's Issues

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 😄

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

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?

pnpx is deprecated in favor of `pnpm dlx`

https://stackoverflow.com/a/70266473

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?

Multisite Deploy

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

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)

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.

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

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.

👋👋👋

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

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.

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!

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?

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.

docker-compose can be replaced with `docker compose`

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

@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

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!

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.

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

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

Dependency Dashboard

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

This repository currently has no open or pending branches.

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.1.1
• react ^18.2.0
• react-dom ^18.2.0
• @types/node ^20.11.24
• @types/react ^18.2.61
• @types/react-dom ^18.2.18
• typescript ^5.3.3

apps/remix-app/package.json

• @remix-run/express ^2.8.0
• @remix-run/node ^2.8.0
• @remix-run/react ^2.8.0
• 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.18.3
• get-port ^7.0.0
• morgan ^1.10.0
• react ^18.2.0
• react-dom ^18.2.0
• @faker-js/faker ^8.3.1
• @playwright/test ^1.42.1
• @remix-run/dev ^2.8.0
• @remix-run/eslint-config ^2.8.0
• @swc/core ^1.3.102
• @swc/helpers ^0.5.3
• @tailwindcss/typography ^0.5.10
• @testing-library/dom ^9.3.4
• @testing-library/jest-dom ^6.2.0
• @testing-library/react ^14.1.2
• @testing-library/user-event ^14.5.2
• @types/compression ^1.7.5
• @types/eslint ^8.56.5
• @types/express ^4.17.21
• @types/fs-extra ^11.0.4
• @types/glob 8.1.0
• @types/morgan ^1.9.9
• @types/node ^20.11.24
• @types/react ^18.2.61
• @types/react-dom ^18.2.18
• @vitejs/plugin-react ^4.2.1
• @vitest/coverage-c8 ^0.33.0
• autoprefixer ^10.4.18
• concurrently ^8.2.2
• esbuild 0.20.1
• fs-extra ^11.2.0
• glob ^10.3.10
• happy-dom ^13.6.2
• msw ^2.2.2
• nodemon ^3.1.0
• npm-run-all2 ^6.0.0
• postcss ^8.4.33
• postcss-load-config ^5.0.0
• start-server-and-test ^2.0.3
• tailwindcss ^3.4.1
• tailwindcss-animate ^1.0.7
• ts-node ^10.9.2
• tsx ^4.7.0
• typescript ^5.3.3
• vite ^5.1.4
• vite-tsconfig-paths ^4.3.1
• vitest ^1.1.3

apps/remix-vercel/package.json

• @remix-run/css-bundle ^2.8.0
• @remix-run/node ^2.8.0
• @remix-run/react ^2.8.0
• @remix-run/serve ^2.8.0
• @vercel/analytics ^1.1.1
• @vercel/remix ^2.8.0
• isbot ^5.1.1
• react ^18.2.0
• react-dom ^18.2.0
• source-map-support ^0.5.21
• @remix-run/dev ^2.8.0
• @remix-run/eslint-config ^2.8.0
• @types/react ^18.2.61
• @types/react-dom ^18.2.18
• @types/source-map-support ^0.5.10
• eslint ^8.57.0
• postcss ^8.4.33
• tailwindcss ^3.4.1
• tailwindcss-animate ^1.0.7
• typescript ^5.3.3
• vite ^5.1.4
• vite-tsconfig-paths ^4.2.3

config/eslint/package.json

• @remix-run/eslint-config ^2.8.0
• @typescript-eslint/eslint-plugin ^7.1.1
• @typescript-eslint/parser ^7.1.1
• eslint-config-next ^14.1.1
• eslint-config-prettier ^9.1.0
• eslint-config-turbo ^1.11.3
• eslint-plugin-tailwindcss ^3.14.3
• eslint ^8.57.0
• typescript ^5.3.3

config/tsconfig/package.json

package.json

• @ianvs/prettier-plugin-sort-imports ^4.1.1
• @remix-run/dev ^2.8.0
• @turbo/gen ^1.11.3
• @types/glob 8.1.0
• glob ^10.3.10
• json5 ^2.2.3
• magicast ^0.3.2
• prettier ^3.1.1
• prettier-plugin-tailwindcss ^0.5.11
• replace-in-file ^7.1.0
• turbo ^1.11.3
• typescript ^5.3.3
• pnpm 8.15.4

packages/business/package.json

• tiny-invariant ^1.3.3
• @types/node ^20.11.24
• rimraf ^5.0.5
• tsup ^8.0.0
• tsx ^4.7.0
• typescript ^5.3.3

packages/database/package.json

• @prisma/client ^5.10.2
• @types/node ^20.11.24
• dotenv-cli ^7.3.0
• prisma ^5.10.2
• rimraf ^5.0.5
• tsup ^8.0.0
• tsx ^4.7.0
• typescript ^5.3.3

packages/internal-nobuild/package.json

• rimraf ^5.0.5
• tsup ^8.0.0
• typescript ^5.3.3
• vite ^5.1.4
• vite-tsconfig-paths ^4.2.3
• vitest ^1.1.3

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.0
• lucide-react ^0.344.0
• npm-run-all2 ^6.0.0
• tailwind-merge ^2.2.0
• @remix-run/dev ^2.8.0
• @remix-run/node ^2.8.0
• @storybook/addon-essentials ^7.6.7
• @storybook/addon-interactions ^7.6.7
• @storybook/addon-links ^7.6.7
• @storybook/addon-onboarding ^1.0.10
• @storybook/blocks ^7.6.7
• @storybook/cli ^7.6.7
• @storybook/react ^7.6.7
• @storybook/react-vite ^7.6.7
• @storybook/test ^7.6.7
• @tailwindcss/typography ^0.5.10
• @types/node ^20.11.24
• @types/react ^18.2.61
• @types/react-dom ^18.2.18
• @vitejs/plugin-react ^4.2.0
• autoprefixer ^10.4.18
• concurrently ^8.2.2
• eslint-plugin-storybook ^0.8.0
• postcss ^8.4.33
• react ^18.2.0
• react-dom ^18.2.0
• storybook ^7.6.7
• tailwindcss ^3.4.1
• tailwindcss-animate ^1.0.7
• tsup ^8.0.0
• typescript ^5.3.3
• vite ^5.1.4
• vite-tsconfig-paths ^4.2.3
• @remix-run/dev ^2.0.0
• @remix-run/node ^2.0.0
• 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

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!

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.