Add monorepo setup like turborepo

[phifa]

Many projects over time get multiple apps, like an admin interface or a separate docs app for example. I found that an initial setup in a turborepo like structure makes it easy for whatever comes in the future. It's easy to add more apps and packages.

 - apps/frontend 
 - apps/backend 
 - apps/admin
 - apps/docs
 - packages/ui: Shared React component library
 - packages/eslint-config-custom: Shared configuration (ESLint)
 - packages/tsconfig: Shared TypeScript `tsconfig.json`
 - ...

Here you can read more about the project:

https://turbo.build/repo

Is there more interest in the community for this?

[kentcdodds]

I've always been monorepo curious, but I've never gone fully into it. I think I'd prefer nx, but I need to compare the two.

Before we actually implement anything as part of the starter, I would prefer to have an example on each to compare. Would you be interested in making a turborepo example repo on your own account?

[mattfysh]

I'd also vote for nx. I've used both and I'm still scratching my head trying to understand how turborepo has become so popular, given that nx has better performance and delivers a more feature-complete experience.

I hesitate to speculate, but I think a lot of turborepo's popularity comes from its attachment with the Vercel brand.

At any rate, turborepo does not have scaffolding which is a glaring omission. They have also decided to invest in a Rust rewrite, which will put them even further behind the nx feature set.

[phifa]

I'd like to bring @PhilDL into the conversation, he has a stack with turborepo going and has experience, maybe joining forces makes sense?

https://github.com/PhilDL/remix-gospel-stack/

[kentcdodds]

More than welcome! I'm pretty particular about the opinions going into this stack though.

[PhilDL]

Thank you for mentioning me, I really like the direction the epic-stack is taking right now as a monolith. But yes I can try to make a version of my gospel-stack with "batteries included" taking inspiration from this stack when I have a bit more free time. It would be a turborepo (I am not familiar enough with NX) where we basically extract functionalities seen here (UI, Payment provider, Emails provider, File Upload, Caching, Queues, Cron) into their own packages, allowing a plug-and-play type experience when composing a remix app. And then we can see if it is interesting.

[sergiodxa]

Since EpicStack is a full-stack stack, what would be the point of a monorepo?

The frontend and backend are part of the same app here.

And if you plan to use EpicStack inside a monorepo then EpicStack itself doesn't need to support anything, you can setup a monorepo with Turbo/nx/lerna/etc and run npx create-remix@latest --typescript --install --template epicweb-dev/epic-stack app/my-app inside your monorepo to have a new app created.

[kentcdodds]

This is where I'm at as well, but I do know that some folks like having multiple apps in a single repo so they can easily share components. So I think having an example showing how to accomplish this would be quite helpful. But I don't think it'll be part of the default template.

[tomslutsky]

Agree. It can be beneficial to have an example for that.
A use case I want to try is having a Remix app and a React-Naive app communicating with the Remix backend using trpc

[kentcdodds]

That would be awesome to see!

[agcty]

We're also consolidating our codebase into a monorepo to share components, helpers, etc. I do think that most people won't ever need a monorepo with a Remix based app but once you need to manage more and more apps, monorepos are definitely a huge DX win. Would be awesome to see a community based example for monorepos!

[agcty]

After some tries using both NX and turborepo, here are some thoughts:

NX seems much more extensible and better suited for huge monorepos.
Turbo is a little easier to use and understand.

Generally, I try to avoid Vercel related products at the moment, not because they are bad or anything but because there is often a lot of magic involved that I'd rather understand and build myself. However, in the case of NX vs turbo, I must say that turbo, especially for Docker related deploys is much easier to use (at the moment). This is because of the prune command turbo provides https://turbo.build/repo/docs/handbook/deploying-with-docker.

For context, I have been trying to write a Dockerfile that uses pnpm workspaces and NX. First of all, it seems you don't necessarily even need NX or turbo at all if you don't have packages that depend on each other. The main benefit of these tools is that they orchestrate the build order and cache it. Yes, caching by itself is a good benefit but that doesn't really matter when your build times are really short, possibly because your project is small and doesn't have a lot of cross dependencies, if any.

Without NX or Turbo
You can copy over the root package.json etc files and then your specific packages in another step and use a command like pnpm --filter to install the necessary dependencies and build the project. This works but is a little tedious if you have a nested structure.

FROM node:16
 
WORKDIR /usr/src/app
 
# Copy root package.json and lockfile
COPY package.json ./
COPY package-lock.json ./
 
# Copy the docs package.json
COPY apps/docs/package.json ./apps/docs/package.json
 
RUN npm install

With NX
You still have to copy over the necessary files

With turbo prune --docker

FROM node:18-alpine AS base
 
FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update
# Set working directory
WORKDIR /app
RUN yarn global add turbo
COPY . .
RUN turbo prune --scope=web --docker

You get a pruned monorepo output like this:

Image taken from turbo docs

This is basically the only reason why I would consider using turbo. You don't have to worry where your package is and can just rely on turbo finding everything it needs which is very handy if you have multiple apps deployed with docker.

[vinstah]

for what it's worth, it might be good to look into Domain driven design if it's mostly about structure of apps within repo e.g admin/tenants/website/api

[Mat-moran]

also @jacobparis has a interesting article about a monorepo with NX an a REMIX app https://www.jacobparis.com/content/remix-nx-monorepo

[steffven]

I tried to install epic-stack into both NX and Turborepo without any luck. A pity, I think. But maybe I need to rethink the architecture I am going for. As an overview, the plan was to have multiple epic-stack projects living under one roof so to speak, with shared dependencies like UI components etc.

[kentcdodds]

That would be very cool and I would love for it to work! Happy to make small adjustments to help make that possible if anyone can suggest what needs to happen.

[steffven]

I'll give it another go over the weekend and provide more info regarding the issues encountered.

[PhilDL]

Hi 👋 if you are interested I am working on putting the epic-stack in a monorepo setup. It's not finished but you can already follow the commit history here:

https://github.com/PhilDL/epic-stack-monorepo

It starts at the second commit with a very basic monorepo setup with PNPM as the package manager (NO turborepo, and NO NX at that step).
The epic-stack remix app has been moved to its own apps/epic-app directory and some common config files are reorganized at the root. This setup (commit 2) is working only for local dev but you could start moving things into their own packages (or wait a little bit until I finish it).

The third commit installs turborepo, fixes the CI, updates the Dockerfile, and deploys to fly.

[kentcdodds]

Thank you for putting that example together!

[steffven]

Thank you @PhilDL, this is super helpful

[kentcdodds]

Now that we have an example, I think I'm going to close this discussion. Feel free to continue the discussion in the example or if anyone have another take on the monorepo problem we can definitely get another example.