Live data from Hacker News

Monorepos in JavaScript and TypeScript

robinwieruch.de

61–70 of 79 posts

Re: Monorepos in JavaScript and TypeScript

#61

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…

Sounds like https://yarnpkg.com/features/zero-installs might be something to help out. Especially if those installs are mostly just filling out a giant set of node modules folders.

Re: Monorepos in JavaScript and TypeScript

#62

Earlier quoted context omitted.

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.

They mentioned trying to use Yarn workspaces. I set up several projects in a monorepo recently using Yarn 3, and while the end result was awesome, the path to success was dark and weedy. It seemed I was constantly 95% of the way there, but some detail or another wasn't quite right. Yarn has no solution for this, because the problem is the integration of tooling. eslint, typescript, prettier, jest, relay, you name it.…

You might mean with pnp as the node linker? Migrating to yarn 3 from yarn 1 wasn't an issue at all for me with `nodeLinker: node_modules`.

I just wrapped up switching over to pnp though, and that '95% of the way there' line you mentioned rings a bell for me.

Re: Monorepos in JavaScript and TypeScript

#63
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/

Re: Monorepos in JavaScript and TypeScript

#64
post #38

Earlier quoted context omitted.

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.

When people say stuff like this, I genuinely wonder if they actually used lerna. Lerna is more or less a wrapper around yarn/npm, and still 100% totally sucks. Nor does it solve ANY of the problems GP mentions -- which I've also had -- recognizing code from other modules, live-reloading schemas, don't even get me started on jerry-rigging like 8 different webpack plugins because you need sass, but you also need an SVG…

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.

Re: Monorepos in JavaScript and TypeScript

#65
post #18
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’m early in testing but loving for the reasons you describe.

Re: Monorepos in JavaScript and TypeScript

#66
post #38

Earlier quoted context omitted.

When people say stuff like this, I genuinely wonder if they actually used lerna. Lerna is more or less a wrapper around yarn/npm, and still 100% totally sucks. Nor does it solve ANY of the problems GP mentions -- which I've also had -- recognizing code from other modules, live-reloading schemas, don't even get me started on jerry-rigging like 8 different webpack plugins because you need sass, but you also need an SVG…

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://github.com/dan-kez/lerna-webpack-example

It only has about 7 config files before even adding any "real" code. Fun stuff.

Re: Monorepos in JavaScript and TypeScript

#67

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…

Take this advice with a grain of salt cause I'm not an expert.

You can save the contents of the yarn cache directory between builds. Set it with the YARN_CACHE_FOLDER environment variable.

Build an intermediate docker image with all packages built. Later images can be based from that and don't need to rebuild.

Re: Monorepos in JavaScript and TypeScript

#68

Earlier quoted context omitted.

They mentioned trying to use Yarn workspaces. I set up several projects in a monorepo recently using Yarn 3, and while the end result was awesome, the path to success was dark and weedy. It seemed I was constantly 95% of the way there, but some detail or another wasn't quite right. Yarn has no solution for this, because the problem is the integration of tooling. eslint, typescript, prettier, jest, relay, you name it.…

You might mean with pnp as the node linker? Migrating to yarn 3 from yarn 1 wasn't an issue at all for me with `nodeLinker: node_modules`. I just wrapped up switching over to pnp though, and that '95% of the way there' line you mentioned rings a bell for me.

I did try pnp and in some ways it seemed promising, but it wasn’t the right fit for what we wanted at the time.

You’re right, most of it did work using node_modules as the linker, but I found things like having eslint configure itself from typescript inexplicably blew up and resolving those issues wasn’t trivial.

I mean, it was on and off work for a week or so, migrating a few apps and packages (including a react native app, that was a big part of the motivation and struggle in the migration in the first place), so all in all it was acceptable. And the productivity gain was more than worth it. It just wasn’t as trivial as we expected/hoped.

Re: Monorepos in JavaScript and TypeScript

#69

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

Premade monorepos are fine, I’m sure, but My experience is trying to fix a poor development situation that might benefit from synthesizing several repos, but modifying existing setups is extremely fragile, never straightforward, and therefore hard to justify the time expense to your team.

Re: Monorepos in JavaScript and TypeScript

#70
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"?

Sounds like requirements Nix solves
Post reply on HN