Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepos in JavaScript and TypeScript

robinwieruch.de

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Monorepos in JavaScript and TypeScript

#51

Post by TameAntelope »

You know, I'm currently using a monorepo concept for the backend of a project, and I think I'll soon split it up into multiple repos, with a shared base Docker container for the generated code they all share (ORM database models).

The problem with my plan is that I know from experience that making changes to the shared Docker layer is a pain in the ass to get it to propagate across your other projects as you're developing it, at first. Once you learn the incantations to chant, it's quick.

I just don't want to have to teach my team the incantations. It takes time!

If we get another round of funding and/or I find out I'll need to care about this project for more than a few additional months, I will likely make the switch, but at this point I can probably white knuckle my way into whatever exit we end up with.

And honestly, I think this is how the decision should be made; entirely dependent on a) your team and b) your anticipated future state of your work environment. No right answers here, just more or less complex ones with better or worse tradeoffs.

Re: Monorepos in JavaScript and TypeScript

#52

Post by sbf501 »

kayson wrote: post #12

I had an extraordinarily hard time getting a monorepo set up for a proof of concept for a pretty basic dashboard app. I was using react for the frontend, node for the backend (Typescript for both), and GraphQL for the API. I tried both npm and yarn for "workspaces" but neither really made things any easier. What I wanted most of all was a repo where both frontend code and backend code were based on the same single-so…

Same thing here. I think tooling (packers included) aren't really designed for this, as demonstrated by the hacks you need to apply to aliases and directories. I hope this is fixed over the next few years, because like you, I got it to work but it is fugly.

Re: Monorepos in JavaScript and TypeScript

#53

Post by davidatbu »

jpgvm wrote: post #46
davidatbu wrote: post #36

Earlier quoted context omitted.

I'm super curious, what would you recommend for a tech stack that "[has] a good build system, good incremental compilation, proper test framework integration, etc"?

Personally Kotlin/JVM. Gradle gets the job done, incremental (and concurrent) builds are fast, etc. You can also use just plain Java if you prefer if you really want a very fast compile time. Arguably Golang is decent here but it's not my cup of tea for other reasons but you do have to admit it has a very fast compiler and the way it's package system works makes for good incremental build support. .NET has always bee…

Thank you very very much for taking the time to write that out!

Re: Monorepos in JavaScript and TypeScript

#54

Post by taeric »

kayson wrote: post #12

I had an extraordinarily hard time getting a monorepo set up for a proof of concept for a pretty basic dashboard app. I was using react for the frontend, node for the backend (Typescript for both), and GraphQL for the API. I tried both npm and yarn for "workspaces" but neither really made things any easier. What I wanted most of all was a repo where both frontend code and backend code were based on the same single-so…

I'm having PTSD thinking back on doing this with WSDL files back in the day.

Thinking on it, not much different than having a protobuf layer generate data objects across apps. Combined with any client generation logic, we are basically there.

Just, realize that these being separated in repo is also a benefit, since that mirrors how they are separated by deployment.

Re: Monorepos in JavaScript and TypeScript

#55

Post by moltar »

dgb23 wrote: post #9

I'm currently evaluating/tinkering with an idea: I think that a well structured monorepo might make a move away from all-encompassing full-stack frameworks and plugins to libraries, tools and special purpose frameworks easier to get close to a best of both worlds situation. The background is deploying up to a dozen or less new sites and apps per year as a small team while continuously maintaining the old ones and wan…

I’m experimenting with same. Turbo, projen. Please contact me via email in the profile. I’m super keen on sorting that out.

Re: Monorepos in JavaScript and TypeScript

#56

Post by jupp0r »

The premise of the article and the usage of the word and concept of "monorepo" used by many organizations is misguided.

A monorepo is not just a bunch of projects thrown together into one repo. It's the philosophy of having all code of a bigger organization in one repository.

When smaller teams inside of companies start creating "monorepos" for a hand full of projects, they end up with many "monorepos". This approach combines the worst of both worlds: you get the tooling complexity and scalability problems of monorepo combined with the inability to make atomic changes over multiple projects. You get none of the benefits.

If you are thinking about moving to a monorepo, do it in a way that

- has everything required to build a deployable unit into the repo, no dependencies to other repos

- under no circumstances have code in another repo depend on code inside the monorepo

- avoids ending up with dozens of monorepos

Re: Monorepos in JavaScript and TypeScript

#57

Post by iRomain »

The article barely mentioned the other tools like Lerna and Nx as if the author didn’t try them. For such a deep dive I would expect the author to check out the tools that will have solved many of the problems one could encounter setting up and using monorepos.

I tried https://nx.dev/ in the past and it helped with many things. You should check it out.

Re: Monorepos in JavaScript and TypeScript

#58

Post by jkrubin »

I have tried every monorepo manager and all but one were super annoying and difficult. Lerna was slow and annoying. Turborepo felt immature when I tried it. Yarn workspaces didn’t play nice with windows for some reason.

I swear by pnpm + rush (from Microsoft). Fast installs. Good caching. Keeps every dependency in sync. Handles the local workspace builds well if you buy into their build tool, heft (which I have).

Re: Monorepos in JavaScript and TypeScript

#59

Post by deathanatos »

Okay, but how do I get CI for it to not be slow as molasses? I'm just a backend/infra eng, but while I know some JS/TS, I'm not an expert; `yarn install` (which is all the CI section seems to cover) is slow.

We have a monorepo with about equal gigantic parts Rust & TypeScript. The Rust part builds ~1100 crates in ~8 minutes, and runs all the unit tests after another ~9 min. (~17 min total.) The yarn install part of our CI takes ~39 minutes. (Not really sure how to do a "# of crates" style comparison.) (And at 39 minutes, this is very much on CI's critical path. The Rust stuff … isn't. The irony of a compiled language beating the pants off one that is only sort-of isn't lost on us.)

Re: Monorepos in JavaScript and TypeScript

#60

Post by lmm »

coding123 wrote: post #47

One thing I don't understand about monorepos is that do people just stay on one platform and check in binaries? Or is it assumed that everything must be compiled and correct. I get that a branch can be compiled, tested and integrated, but how does that work with multiple teams. I mean at what point does it become like week-long builds to make sure everything is accurate and correct. Or is monorepo more of a "place to…

You'd generally have a CI build with some combination of heavy caching, incremental build, and reverse dependency detection, so that it can rebuild and test everything that's changed in a given PR without taking forever. I've worked in places that had a dedicated team of senior people maintaining the build and virtually a full outsourced team contributing to the open-source build tool to support that.
Post reply on HN