Live data from Hacker News

Monorepos in JavaScript and TypeScript

robinwieruch.de

31–40 of 79 posts

Re: Monorepos in JavaScript and TypeScript

#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 Typescript compiler (well type-checker really, it doesn't compile anything) is horrendously slow and has poor incremental support.

If you are writing a sufficiently large application you are just better off switching to a mature tech stack than dealing with how awful the TS ecosystem is.

Ideally something with a good build system, good incremental compilation, proper test framework integration (so tests only run when input classes/objects are changed) etc.

Re: Monorepos in JavaScript and TypeScript

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

Lerna is one of those "this works great!" or "this is a huge dumpster fire!" solutions. I've seen more broken lerna monorepos than I can count. Recently I've made quite a little side career of fixing lerna monorepos, replacing it wholesale with pnpm's abilities.

Re: Monorepos in JavaScript and TypeScript

#33
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…

Lerna is defunct? Can you link any blog post about it? I thought the JupyterLab team was using that for their monorepo.

I do not like the prospect of having to use a TS/JS specific build tool, because of wanting to use monorepo, but fortunately, I did not yet have to do that, as I only ever developed extensions, and did not fork JupyterLab, to change anything core. Lerna and the whole setup brimborium is definitely something that scares me away from even trying to change things in the core.

Re: Monorepos in JavaScript and TypeScript

#34
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…

Lerna is defunct? Can you link any blog post about it? I thought the JupyterLab team was using that for their monorepo. I do not like the prospect of having to use a TS/JS specific build tool, because of wanting to use monorepo, but fortunately, I did not yet have to do that, as I only ever developed extensions, and did not fork JupyterLab, to change anything core. Lerna and the whole setup brimborium is definitely s…

https://github.com/lerna/lerna/issues/3121. It looks like maintenance of lerna is being passed to the company behind nx. They promise continued support of lerna, but who knows what the future will bring.

Re: Monorepos in JavaScript and TypeScript

#35
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…

what do you dislike about nx?

Re: Monorepos in JavaScript and TypeScript

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

Re: Monorepos in JavaScript and TypeScript

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

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. They each want to work together and integrate with each other in different ways, using various sources of truth, and so on. Then your IDE needs to adhere to the same protocols, but various extensions have different opinions about default configurations.

Along the way you really need to know your tooling deeply, or you're in for some suffering.

Relatively simple projects with full buy-in of Yarn 3's tooling are probably pretty easy. Once you get relatively complex though, I don't know, I don't think any of this is easy.

It does sound like Nx handles a bunch of this stuff for you, which I'd love to try out. I really like that Yarn isn't particularly opinionated though. Once I had things set up, there was very little to change or that could break. The scaffolding was fairly plain to see, easy to work with, and we owned it. With something like Nx where things reportedly "just work", I worry it would be an unsettling blend of black boxes and black magic making my tooling and code work... Until it didn't, at which point I'd wish I used something less opinionated.

Re: Monorepos in JavaScript and TypeScript

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

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 loader, and also a JSX loader but oops now you're running into some weird conflict between them, etc. etc.

It's honestly embarrassing that modern web development (an incredibly "dumb" network protocol at its core) doesn't have an easier onboarding/development process.

Re: Monorepos in JavaScript and TypeScript

#39
post #32

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.

Lerna is one of those "this works great!" or "this is a huge dumpster fire!" solutions. I've seen more broken lerna monorepos than I can count. Recently I've made quite a little side career of fixing lerna monorepos, replacing it wholesale with pnpm's abilities.

I recently discovered pnpm myself and found it to be a significantly better experience. I've been meaning to add something like changesets to it, too.

Re: Monorepos in JavaScript and TypeScript

#40

I've tried numerous times to get monorepos working with React Native/React Native Web but it always winds up falling apart eventually. Yarn workspaces, no workspaces, plain symlinking, relative imports...none of it works consistently, which is a real shame (and certainly RN's problem more than anything else). In a couple I've had to resort to shell functions to rsync built files into node_modules after I make changes…

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

Post reply on HN