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

71–79 of 79 posts

Re: Monorepos in JavaScript and TypeScript

#71

Post by cersa8 »

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 had a similar realization that setting up a monorepo with lerna or workspaces was going to be challenging. For a Next.js + custom TypeScript / Node.js backend I decided to just add the backend in its own folder with a child tsconfig.json. This way you can have the backend compile to its own dist folder. No need to fiddle with the complex under the hood bundling that's going on in Next.js. It gives you a single git repo and backend and frontend share the same typings. To make things easier you can setup paths in tsconfig.json and use module-alias in package.json for things like

  import {IUser} from '@shared/interfaces/users/IUser'

Re: Monorepos in JavaScript and TypeScript

#72

Post by toastal »

paulmd wrote: post #29
TAKEMYMONEY wrote: post #8

Earlier quoted context omitted.

Is it literally just your codebase or a shared one? Generally with submodules we run into issues like each dev having to maintain the setup on their own machine, and unique commands to work with module repositories. For WAY more writeup: https://codingkilledthecat.wordpress.com/2012/04/28/why-your... Whole tools were created to get around these issues (git-subtree for ex).

This isn't the only place this pops up - commit hooks are another example, since they live in .git they don't travel with the repo when it is cloned (or maybe when it is updated, don't remember the specifics). I really feel there needs to be like a git --pull-config option or something to pull all project configs (including submodules, commit hooks, etc). Or perhaps move those things into the top-level folder and all…

You can easily make a `.githooks` directory and have your docs suggest running `git config --local core.hooksPath .githooks`.

This could have security concerns in open source though as users should rightfully be skeptical of running arbitrary code if malicious code is in there (similar to the security issue of your shell hooking into git info in directories and an untarred archive containing `.git` with malicious code in it). However, at least if it's in the docs, it's consensual unlike tools like Husky that inject scripts at runtime as well as creating yet another NPM module to audit.

Re: Monorepos in JavaScript and TypeScript

#73

Post by jpgvm »

toastal wrote: post #70
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"?

Sounds like requirements Nix solves

It helps but Nix just like Bazel can't handle Node.js in a cross-platform way. You still end up reverting to running `npm ci` in a Dockerfile and building the image in imperative style, giving up hermetic and reproducible builds in the process.

The reason this is needed is node_modules contains platform specific native code. You can somewhat speed up cross-arch/OS builds by explicitly running the appropriate node-gyp incantation to rebuild the native components and skip entirely re-generating node_modules but that is still ultimately a bit gross.

Compared to what you can achieve otherwise with Nix dockerTools.buildImage, Bazel docker_rules or Google's jib tool for JVM it's not even close to the same league in speed, reproducibility, convenience or maintenance overhead.

Re: Monorepos in JavaScript and TypeScript

#74

Post by halfmatthalfcat »

dvt wrote: post #66
halfmatthalfcat wrote: post #64

Earlier quoted context omitted.

Lerna is more akin to loop than it is to a glorified wrapper around yarn/npm, so I question whether it is you who have actually used lerna. All of the "linking between projects" is exactly what lerna does with bootstrapping/hoisting, so I'm not sure where you're coming from when you say this doesn't address OP's problem.

> glorified wrapper around yarn/npm This is exactly what it is, and it's not even shy about it. It literally calls npm or yarn under the hood (specified with the `npmClient` setting). > All of the "linking between projects" is exactly what lerna does with bootstrapping/hoisting, so I'm not sure where you're coming from when you say this doesn't address OP's problem. Yeah, here's a "super simple" lerna example: https:…

It only relies on npm to do the actual pulling of packages and if you so choose, let yarn do the hoisting (workspaces) but everything else, I fail to see how it's simply a wrapper...

There's a ton of stuff like versioning, linking, running scripts/commands, etc across the entire project that npm and yarn do not inherently support.

I definitely think lerna has warts but it provides a ton of functionality that you'd have to ducktape together on your own, which it looks like a lot of people are trying to do as evident by this entire thread...

Re: Monorepos in JavaScript and TypeScript

#75

Post by eezing »

Been doing this for a couple years.

We use NPM v8 for packages. Yarn v1 is falling behind and v2 is on a different planet. The other package managers have too much trickery.

Turborepo is fast, simple to use, and very active at the moment.

NPM v8 with Turborepo has eliminated all of our custom monorepo tooling.

Re: Monorepos in JavaScript and TypeScript

#76

Post by eezing »

halfmatthalfcat wrote: post #25
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…

Surprised you haven't heard of or used lerna (with yarn workspaces), which is the defacto monorepo setup in JS world. I use it to maintain a bunch of monorepos and works pretty flawlessly.

True 3 years ago. NPM and Turborepo is all you need today.

Re: Monorepos in JavaScript and TypeScript

#77

Post by mattgreenrocks »

john-shaffer wrote: post #63
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…

Polylith does a good job of solving this: https://polylith.gitbook.io/polylith/

I really like the aim of this, but I have a hard time following the terminology, despite being someone who preaches and teaches functional core/imperative shell.

Re: Monorepos in JavaScript and TypeScript

#78

Post by rzarate »

twblalock wrote: post #45

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. Depende…

Can you elaborate on the kind of in-house tooling that is essential to keep monorepos sane?
Post reply on HN