4 ms·

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 f

by kayson 4y ago

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-source-of-truth GraphQL schema, so that everything was strongly typed, avoiding any kind of API inconsistencies. In the end, I never got things working the way I wanted. The hardest thing was getting Typescript (and worse, VScode) to recognize code across modules. The second hardest thing was getting GraphQL schema types into the frontend and backend. There's a huge ecosystem around GraphQL development, especially if you're using JS/TS, but it's still all so clunky. I ended up using a handful of tools to 1) generate the schema from the backend code, 2) serve it via introspection on the backend dev server (thank goodness for hot reloading), and 3) watch said backend schema and generate static type files for the frontend. Did it work, sure. Is it elegant and straight forward? Definitely not. What a mess!

Alonski 4y ago
I recommend taking a look at RedwoodJS
- hi 4y ago
  +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
- kwerk 4y ago
  +1, I’m early in testing but loving for the reasons you describe.
halfmatthalfcat 4y ago
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.
- leetrout 4y ago
  Was the defacto? Learna needed a new maintainer and is now moving to Nrwl who develops Nx and seems to be the better choice for future projects? https://nx.dev/ https://nx.dev/
- andrew_ 4y ago
  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.
  - douglasisshiny 4y ago
    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.
- steve_adams_86 4y ago
  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.
ThomasRooney 4y ago
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/.yarnrc.yml 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/packages/schema/schema.graphql https://github.com/ThomasRooney/reamplify/blob/master/packag...
sbf501 4y ago
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.
taeric 4y ago
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.
cersa8 4y ago
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'

by kayson 4y ago

Alonski 4y ago

I recommend taking a look at RedwoodJS

hi 4y ago
+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
kwerk 4y ago
+1, I’m early in testing but loving for the reasons you describe.

halfmatthalfcat 4y ago

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.

leetrout 4y ago
Was the defacto? Learna needed a new maintainer and is now moving to Nrwl who develops Nx and seems to be the better choice for future projects? https://nx.dev/ https://nx.dev/
andrew_ 4y ago
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.
- douglasisshiny 4y ago
  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.
steve_adams_86 4y ago
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.

ThomasRooney 4y ago

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/.yarnrc.yml 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/packages/schema/schema.graphql https://github.com/ThomasRooney/reamplify/blob/master/packag...

sbf501 4y ago

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.

taeric 4y ago

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.

cersa8 4y ago

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'