docs(examples): add turborepo + vercel example

[airjp73]

This was a tricky combination of tools to set up correctly for me, so I figured it made sense as an example.

This example is deployed to Vercel here.

I'm using this same setup in the remix-validated-form docs deployed here.

[remix-cla-bot]

Hi @airjp73,

Welcome, and thank you for contributing to Remix!

Before we consider your pull request, we ask that you sign our Contributor License Agreement (CLA). We require this only once.

You may review the CLA and sign it by adding your name to contributors.yml.

Once the CLA is signed, the CLA Signed label will be added to the pull request.

If you have already signed the CLA and received this response in error, or if you have any questions, please contact us at [email protected].

Thanks!

- The Remix team

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[kentcdodds]

This is great, thank you for taking the time to put this one together :)

[yuraji]

Can we have two Remix apps in a Turborepo? I randomly get a 404 on my deployment whenever I add a second Remix app.

Steps to reproduce: Clone the apps/remix-app to apps/remix-app-two. Update apps/remix-app-two/package.json "name". Deploy two apps to Vercel. One app or both will respond with 404. Delete second app from turborepo and the first one will start working.

What am I missing?

[revelt]

@yuraji did you follow the https://vercel.com/blog/monorepos#creating-projects-from-a-monorepo part, specifically

Repeat this process for each app you want to set up.

[yuraji]

@revelt yes, both projects are created separately, and each pointing to their respective folder in the apps/. Both projects are set up with the build and install config specified in this example.

I had a case when first app worked, until second project was added, at which point second project worked, and the first one responded with 404. And if second app is deleted, first project starts working. It's as if they are stepping on each other's toes. Any idea?

[revelt]

@yuraji Sorry I'm not the best person to help, I moved away from Vercel few years ago (to Cloudflare workers), and now I'm looking to migrate again, to the likes of fly.io and going more full-stack with databases, auth etc. I think a proper CI (even GitHub actions) might scale better than Vercel "builds". For example, I've got many npm packages on turborepo which also need building/testing and I use Semaphore CI for that. From here, my remix sites would also build and test from the same CI and be published to fly or DigitalOcean (I'm still considering all options). My turborepo is here btw, remix site in-progress here.

Generally, I'd debug step-by-step. I'd comment-out my semaphore yml and go line-by-line: does it build what it is supposed to, then does it publish where it is supposed to. Now, that's harder to do on Vercel "CI", something's probably misconfigured. For example, I'm looking at this very example's setup:

Do you see the problem? One of the projects is "going up" to the monorepo root and triggering turborepo build script. That's not right! So what does the second project do? That's what I mean by having a proper CI, controlled by yml workflows — a good foundation solves most of the problems outright. If very bootstrapped, one can use free GitHub Actions and have Vercel "build" disabled.

Sorry I'm not much of a help =)

[yuraji]

Almost sounds like they might be conflicting during the build, doing the same build twice at the same time. And since rollup and fs are involved, things may not be perfectly aligned.