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

41–50 of 79 posts

Re: Monorepos in JavaScript and TypeScript

#41

Post by hi »

Alonski wrote: post #18
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 recommend taking a look at RedwoodJS

+1 I've been using RWJS for the past 2 years and would recommend giving it a try:

> yarn create redwood-app my-redwood-project --typescript

Re: Monorepos in JavaScript and TypeScript

#42

Post by mattgreenrocks »

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…

Ruby had a tiny movement going for awhile that was similar to this: Rails delivered your app, and the core domain logic should be confined to a gem that the Rails app depends on.

I don’t think it caught much traction; sadly people seem to prefer doing the easy thing over the simple thing.

Re: Monorepos in JavaScript and TypeScript

#44

Post by ThomasRooney »

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…

My experience was very similar: I built an application using a GraphQL schema file that powered AppSync templated VTL/DynamoDB tables, as well as automatically generating GraphQL operations/types. When I cleaned up the application's template for reuse, I erroneously decided to try out Yarn 3/Lerna/PnP, and then lost an embarrassingly long time to make it work.

Each [1] tool [2] seemed [3] to break differently, and needed some form of manual massaging to make it work. That manual massaging meant learning a new configuration file syntax, multiple times.

When it worked, it felt magical. Weaving together an entire web app, powered by a small bit of GraphQL schema [4] means building at a high level of abstraction (hence can be very productive). The only issue is the muddy forest of the NPM ecosystem you're surrounded by: any step towards upgrading your external dependencies seems to cost far more time than promised.

[1] Yarn3/PnP seems to assume all packages define their dependencies correctly. Unfortunately, this isn't true in the real world. I spent hours massaging dependencies in https://github.com/ThomasRooney/reamplify/blob/master/.yarnr...

[2] Getting TypeScript to work cleanly both in an IDE (IntelliJ) and when imported across backend/frontend packages was really cumbersome: I ended up just emitting .gitignored JS files next to their associated TS.

[3] Whispering into the IDE to make it understand GraphQL required learning the .graphqlconfig syntax, and fine-tuning it.

[4] https://github.com/ThomasRooney/reamplify/blob/master/packag...

Re: Monorepos in JavaScript and TypeScript

#45

Post by twblalock »

My experience with monorepos is that they are excellent if, and only if, you have a team dedicated full-time to making sure the repo remains sane.

This is true for any programming language. (Also, successful monorepos can be polyglot.)

If you don't have a dedicated team, you will eventually end up with all the downsides of a monorepo and few of the benefits. Builds will break frequently, impacting many teams. Dependency management will become a nightmare.

Open-source tooling like Bazel will only get you so far -- you will need in-house tooling too, but more than that, you will need an in-house culture of behaving well in a monorepo. Unless most of your engineers have done it before, you will need strong leadership to build that culture.

If you can't dedicate a team to that purpose and really follow through with it, then don't even try having a monorepo. Do a repo per team, or a repo per project.

Re: Monorepos in JavaScript and TypeScript

#46

Post by jpgvm »

davidatbu wrote: post #36
jpgvm wrote: post #31

Javascript and Typescript to an even worse degree are awful monorepo citizens. Beyond requiring an absolutely ludicrous amount of configuration they also don't fit into existing build tooling well, i.e Bazel, Gradle, etc. The tools created to work around this (lerna - now defunct, nx - awful) are entirely specific to the JS/TS problem and aren't sufficiently general to handle polyglot repos. On top of all that the Ty…

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 been very good in this regard.

Rust is a bit slower on the compiler end but it's still very good, incremental support is good etc.

All of these languages can also either produce code that works on all targets (JVM/.NET) or cross-compile natively (Go, Rust). This matters for packaging and deployment as half of devs use MacOS but deployment target is usually Linux and increasingly containers. Being able to construct Docker containers directly from artifacts without needing Dockerfiles is a huge win and all of the above languages support that via one tool or another (Bazel, Jib, etc).

Literally any of these blow TS out of the water for DX, performance and tooling. Unless you are chained to TS for browser reasons or isomorphic code requirements it's just not worth it on the server.

Re: Monorepos in JavaScript and TypeScript

#47

Post by coding123 »

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 put all the code" not necessarily correct or working.

I like multiple repos because it's easier to assume that the main branch of each is "correct and tested and excellent quality".

Re: Monorepos in JavaScript and TypeScript

#48

Post by chrisweekly »

I have mixed feelings about monorepos, but FWIW my most recent consulting client found success using Nx (combined with pnpm). It's not perfect, but it seemed like an improvement over lerna or yarn workspaces without being as "alien" as something like rush. /$.02

Re: Monorepos in JavaScript and TypeScript

#50

Post by joshgachnang »

nwienert wrote: post #40
aporetics wrote: post #7

Earlier quoted context omitted.

I’ve had the same problem.

The tamagui base starter repo is a monorepo with typescript, react native and web all working together[0] which you can get running with by simply doing: npx create-tamagui-app@latest [0] https://github.com/tamagui/starters/tree/main/next-expo-soli...

Thank you, I'll give this a try when I get a sec!
Post reply on HN