Guidance on current usage with Lerna and Yarn Workspaces?

[jannisg]

I am currently setting up a fresh monorepo structure using Lerna and TSDX to build out a component library.

I have read and followed the various links related to #122 but wanted to check if there is anything to consider when using TSDX inside a lerna monorepo before some kind of official monorepo template (might) land.

My current thinking is to:

1. Setup the monorepo via lerna as normal
2. Setup the yarn workspaces integration with lerna
3. Add tsdx as a devDependency at the root level
4. Run npx tsdx create mylib-package-a for each package inside the packages/* folder
5. Add npm scripts at the root level that use lerna run [flags] to either start, watch, test or build each individual package folder as one command.

Is that roughly the right approach for using TSDX inside a monorepo structure?

[swyxio]

try it and let us know? i dont really use lerna

[jannisg]

@sw-yx It will take another week or so until me and the team will be actively developing this project inside the monorepo + tsdx structure but I will note down my approach and any potential pain points as I go and post an update asap.

I figured I would create this issue since it seems @jaredpalmer does use monorepo's within his organisation (see https://github.com/palmerhq/monorepo-starter) so I thought there might be some general advice that could be put here and eventually distilled into a readme entry but I'm happy to document and post my experience here and then we can decide if a readme section is worthwhile pursuing :)

[zenyr]

Currently if you set up monorepo with lerna and tsdx, tsdx builds via lerna run or lerna exec -- tsdx build will run properly as you'd expect.

But, running tsdx watch in similar way will hang at the first package, as lerna will wait for the first watch command do finish before moving on to the next package. One way to cheat this woud be --parallel flag but this is infamous as a yolo solution. Hmm..

I think this is natural and inevitable for current lerna design. I'm currently stuck at this issue and looking for a solution or idea.

[jannisg]

@zenyr What's wrong with the --parallel flag, seems like a reasonable thing to do here?

Or are you referring to the note in the lerna docs?

Note: It is advised to constrain the scope of this command when using the --parallel flag, as spawning dozens of subprocesses may be harmful to your shell's equanimity (or maximum file descriptor limit, for example). YMMV

[pcowgill]

I think there's room for a separate init config for tsdx that configures a lerna-friendly version of a tsdx project. lerna and monorepos are common enough that a feature like this will help a lot with adoption of this lib.

I've been following roughly this approach, but needing to remember to modify a few of the instructions given that I'm using tsdx rather than tsc directly. And doing this much tsconfig wrangling sort of defaults the purpose of using tsdx.

[arvigeus]

Will this help?
https://gitlab.com/arvigeus/react-modern-state-management
Work in progress...

[ncphillips]

What's wrong with the --parallel flag, seems like a reasonable thing to do here?

@jannisg this can break your builds. Lerna links the packages together and orders builds based on the dependency graph:

If you have three packages:

  A => B => C

Lerna will build these in order: C, B, and then A.

This is necessary. When you use --parallel it might try to build A before it builds B then A's build will break because it can't find the type definitions of B.

[slorber]

Hey,

To me, the best is to build once, and then run watch in --parallel with the --noClean option.

Problem is that currently, the watcher is only looking for changes in ./src, so your symlinks will not be watched (+ they might be hoisted).

tsdx/src/index.ts

Line 328 in b21d7af

include: ['src/**'],

Will see if I can send a PR for that, but was not very successful with patch-package :/