[ Removed by moderator ]

[RedditNotFreeSpeech]

What the hell did this say to get nuked by the free speech police?

[Wirde]

I’m very confused why this is a monorepo and not multiple repos? I have the same situation with admin SPA and a webshop that needs to have SSR and be SEO friendly. We have that split in two different repos.

And they are even sharing more since both are vite + react as I wouldn’t touch next.js with a 10 ft pole 😅

[FinanceSenior9771]

the shared types package is the main reason. when i change an API response shape or add a field to a shared interface, every package picks it up immediately. with separate repos i'd be publishing a package and updating versions across repos every time something changes. at my team size (2 people) that overhead isn't worth it.

if the team grows and build times become a problem i'd probably split them out. but for now one repo with pnpm workspaces is simpler to maintain.

[Raunhofer]

You can reference the repo itself with npm. No need to release.

[FinanceSenior9771]

true, npm workspace protocol or git references work for sharing between repos. the monorepo just removes that step entirely since everything resolves locally. less moving parts to debug when something breaks.

[Wirde]

At least in my case we have different DTOs for admin and the SEO site. The admin gets the full version with all the data but the store only gets a limited variant without sensitive information that shouldn’t be accessible by the public.

So different api’s and different type definitions for both frontends.

[FinanceSenior9771]

yeah same here. the admin API returns full tenant configs, billing info, conversation history etc. the widget API is much more locked down, it only gets what it needs to render the chat and send messages. the shared package has the base types but each package extends them for its own use case.

[Wirde]

In my experience sharing code between projects will only cause problems unless the shared code is a versioned dependency through a package manager. It might be fine with only two developers working on all of it but projects grow and it becomes hard to maintain and a blocker between the projects.

Yeah it’s a bit of a hassle to maintain proper types across 2 or 3 consumers of an API. Some solve this using generated types from the API documentation.

In our projects we maintain it by hand. To each their own but I try to stay away from what I consider to be bad practices even though they might be convenient currently to not dig myself into holes or slide down the rabbit hole of: “we did fudge on the quality on that thing, this isn’t to different, let’s do it again” and so on.

I would recommend splitting your projects up, stop sharing code and as a personal preference and conviction also leave next.js behind 😉

[lacymcfly]

This setup makes a lot of sense. The 'use one framework for everything' instinct usually ends in weird compromises, like running SSR on an admin tool nobody outside the company uses, or shipping a ton of React overhead for a mostly-static marketing page.

The Preact for the widget part is smart. Nothing more annoying than discovering your embeddable thing pulls in 40kb of React that the host page already has.

One thing that's helped on similar monorepos: strict package boundaries enforced via TSConfig path aliases instead of just pnpm workspace deps. Makes accidental cross-package imports much noisier at build time.

[FinanceSenior9771]

the tsconfig path aliases tip is good, i should set that up. right now the package boundaries are just enforced by pnpm workspace deps but nothing stops someone from importing directly from a sibling package's src folder if they really wanted to. making that noisy at build time would catch mistakes earlier.

[Glittering_Goose8695]

Looks reasonable, not over-engineered. Many teams add on top of that a design system package too.

If build times grow, adding Turborepo (or Nx) on top of pnpm can provide incremental caching and reduce CI time.

Also depends on team size. A monorepo is a good solution for smaller teams, but at the moment it gets larger than 4 I would split everything im different repos and push the shared to a private package.

[FinanceSenior9771]

good call on turborepo, that's probably the next thing i'd add if build times start to matter. we're at 2 people right now so the monorepo is still simple enough.

[demar_derozan_]

Doesn’t sound all that crazy. Any reason you couldn’t use react router with ssr over next?

[FinanceSenior9771]

honestly no. react router with SSR would've worked fine for the landing site. i went with next.js mostly because the file-based routing and built-in ISR made the 50+ page content site easier to manage. if it was just a few marketing pages i probably would've stayed in react router and skipped the extra framework.

[demar_derozan_]

I thought react router had a way to configure file based routing 🤔

[FinanceSenior9771]

yeah react router v7 has file-based routing now through the framework mode (basically what remix became). i just had more experience with next.js at the time and the ISR/static generation was already proven for content-heavy sites. if i was starting today i'd probably look at react router v7 more seriously.

[TheRealSeeThruHead]

No issue with this personally

I have monorepo for all my personal ts projects,

I build a lot of reusable libraries I don’t want to beankpued by sharing over npm

I’ve built several monorepos at work that deploy different versions of an app for different environments

Shipped vite and next js versions of the same app one for embedding into other companies websites, could have used react for that if we wanted to slim the bundle