Devs using monorepos, when and how do you use them?

Kuala Lumpur, Federal Territory of Kuala Lumpur, Malaysia

The open web is dead, long live the open web. ⌐◨-◨

Building /warpcast and /farcaster

— gabrielayuso.com

What are your advice when building a monorepo? Dos and don'ts

I've been working pretty much exclusively in a monorepo for the past 9 years.

When I don't, I wish I were in a monorepo.

Explorer. Code, design, and mountains. Building Fern https://fernhq.com Previously Shopify

Thanks! This is really similar to something we want to build, a design system. However we were thinking to include the apps directly into the same monorepo, but with further reading based on the comments, it might be wise to separate the apps from libraries/frameworks.

We do at Shopify, here’s a good example https://github.com/Shopify/polaris

Next = NextJS? I'm not familiar with forge..

contracts+f/e+subgraph in monorpo works just fine™️
(powered by turborepo, next, forge, typechain)

Senior prompt engineer. Shipped on farcaster: @larrybot, @qdau, @frames, @framesfun, /open-frames, farcasterchannels.com, farcaster.id, @mod, @search, @discove

I noticed discove's repo isn't public, would you be able to share on how your repo is structured?

reusing code across discove web, react-native and backend services

Smart Contract Engineer at M0
pierrickgt.twitter
https://pierrick.turelier.com

Would you say it's better to use a monorepo to group utilities or packages together and then reference them as dependencies in other repos, i.e. different products/projects?

Using Lerna in this one: https://github.com/pooltogether/v4-autotasks
It's great when you want to share helper functions across various packages.
You don't have to go update each repo one by one.

I like baking /goodbread and building apps on web3 protocols. DevRel @ ENS Labs. gregskril.com

Would you use a monorepo that uses different languages in its packages? Example a python flask project and a nextjs project that uses a common design system built on react.

for this repo, how is your release management be like? compile a sub repo, copy artifacts, deploy?

Backend + frontend when it can’t be done together in something like Next.js but I’m not likely to use the backend anywhere else. Here’s a recent example https://github.com/gskril/ens-adoption

We have all of our code in one repo. It's just easier. See a line of copy I want to change? Grep the whole repo for it, find it

🔍 ensdata.net ✦ 🖼️ pugson.net/rfe ✦  🌐 metadata.vision ✦ 𝙽𝙾𝚆: design engineer @family ✦ 𝙿𝚁𝙴𝚅: @rainbow 🌈

I'm exploring the idea of having different projects under the same repo, i.e. Different products (each product has it's user & internal facing portals and api backends) They may or may not share similar business logic across products.. I can't wrap my head around the idea of a repo that holds them all...

i don't think i've ever been in a monorepo that didn't suck

Optimism uses a monorepo. We have many packages and services that need to be updated simultaneously to stay in sync. 
It also makes it easier to run Integration tests and manage CI. 

For us I can’t imagine how we would function without a monorepo.

Google uses a monorepo for 100% of their code. Pretty neat

We use a monorepo for our frontend and backend. Sharing code is easier

we use a monorepo for both hubs and warpcast apps

A monorepo with well-organized sub directories is the same as having different repos. But better. You are always sure to have the latest version of each component.

i think most startups should probably just mono repo, its good and convenient for managing products with many services (<20)

When? Always!

Amazing for universal apps + design system: https://github.com/showtime-xyz/showtime-frontend

Unless you’re a big org with people dedicated to making this work, don’t do it. This is the modern version of “MSFT had their meetings on the 3rd floor so we should too” type of thinking.

We used one at Uber ATG, I loved it, but it requires a lot of work.

My rating

- building a monolith: cool, why not
- building microservices: cool, why not
- building as many packages: cool, why not
- building many packages as monorepo: why? Just whyyyyy? And yes, „oh but Google does it“ isn‘t a technical argument u fukin LARP

We use monorepo for our nodejs backend code with turborepo. Multiple services with shared utils + models. Single, unified CI flow for automated builds and deploys. Major benefits imo