TypeScript Monorepos Done Right!

[@nxdevtools]

Check out the full blog post: nx.dev/blog/new-nx-experience-for-typescript-monorepos 👋 If you're struggling with exactly these TypeScript performance issues in large workspaces, reach out. We've helped a lot of large enterprises fix exactly that, so talk to us: bit.ly/4hriXac

[@fffantotal]

Seriously these were two points i ran into in the last few months again and again and again. Glad to see it being tackled. Thanks Nx team!

[@Scapben]

can't wait to try that 👀

[@idanguttsait]

Quick question about the distribution of type checking and the time savings. In the old benchmark, it shows the the entire process could have taken 11 minutes, and in the new benchmark the total time is said to be 22 minutes. What is different about the benchmark? Does each individual typecheck command have such a high overhead? If one does not use NxCloud for their CI, would this change incur a 2x performance degradation for that? I believe I'm missing something but please enlighten us as those numbers clearly reflect something different than I would expect.

[@juristr]

Hey! yeah good question. the 22min are an estimate of running everything serially, something you wouldn't do even without nx cloud/locally as you'd run at least 3 in parallel. But fair enough, I'll check with the cloud team how this estimate is being computed. RE overhead: there will always be a little overhead when spawning multiple processes, but here in this benchmark it is really about not being almost able to run typecheck vs being able to break it up into smaller pieces and run it much faster. You can experiment it with it by yourself (note this isn't a scientific benchmark obv, but just to make the point): - without TS proj refs: github.com/jaysoo/ts-bench-old - with TS proj refs: github.com/jaysoo/ts-bench-new I ran it locally and here are some numbers on my M2 MBP of just running "typecheck" Without TS proj refs: - had to increase max heap size and the process did go up to ~11 GB of RAM - took roughly 8,5 minutes With TS proj refs and the new setup: - ran with default Nx settings, so 3 typechecks in parallel: 3,3 minutes - also directly ran it via TSC, which you can since we setup TS proj refs properly. Just run "tsc -b" at the root; that one went up to ~3 GB but stable and took 6 min to run But again. You will notice these benefits in really large monorepos. And we started looking into this mostly because we have huge customers which suffer from exactly this and were going to manually start maintaining TS proj refs (so you know the level of pain they felt 😅). On small repos you'd not use it as the normal typechecking would be "good enough", but given the TS proj refs is automated via the nx sync command now, it's basically for free.

[@idanguttsait]

@ thanks Juri, appreciate the response! Thank you for you and your team’s hard work ❤️

[@kousheralam]

when nx first release i was very happy with it, but over the time when my project grow, nx start throwing weird and harder(at least for me to solve) error. Then i migrate my app to other platform(i do not want to mention it in nx chanel) till now it is serving me well. But i still want to thank nx team for their hard work,

[@juristr]

Sorry to hear that. Feel free to reach out. would love to hear more what exactly was hard(er) to solve

[@clevermaniac]

Been trying to creare pure js react monorepo for weeks now but it has never worked. any resource on the same or perhaps make vide on pure javascript with no typescript whatsoever. just pure js monorepo. I'm yet to find a good resource with a working demo

[@juristr]

Thing is, now most React (and others as well) frameworks just suggest going with TS by default. Still, you should be able to use your CLI of choice, create a JS based React setup and have it in a NPM workspaces monorepo. You could even still use Nx for the task running and caching via package.json scripts. That'd work.

[@clevermaniac]

@@juristr I love Nx so much. if only it was able to create a pure js based react monorepo with shared component library without typescript anywhere. i feel like that should be an option. typescript is great but some old projects of mine are still js based. And I want all of them to be in one monorepo and have a shared library components and other resources. have tried all tutorials and resources on Nx including "Nx import" command but I haven't been able to have share component be accessible across all the apps. it just won't work it should be a option on nx CLI to pick pure js react based app and libraries under the monorepo

[@puzzlegame7359]

Typescript referencing not working properly in modulefedration Microfrontends, compile time its running properly when it comes to runtime on the browser it shows. index.js:492 [webpack-dev-server] ERROR in ./src/app/app.tsx 4:0-37 × Module not found: Can't resolve '@shared/store' in '\apps\hostApps\platformShell\src\app' ╭─[4:22] 4 │ import { store } from '@shared/store'; · ────────────── in tsconfig.app.json "references": [ { "path": "../../../packages/store/tsconfig.lib.json" } ]

[@MrREALball]

Tbh, 11:07 watch-deps command isnt really that good of a fix. You still need to build the library and if it takes a lot of time (e.g. a really big ui library that takes, say, 20-30 seconds to build, mainly because of d.ts generation) it wouldn't be a good developer experience. With simple path aliases it would be instant. Also, didn't know nx has some kind of typechecking command, wasn't able to find it a year ago. Could you point me in the right direction in the docs? I'd like to typecheck my entire monorepo in one task. Right now we setup tscheck task for each package by ourselves, and there is a lot of overhead, since the packages are typechecked first by themselves, than again in everything that depends on them. For our usecase (not using nx cloud), it would be A LOT better to have one tscheck command.

[@juristr]

You can still setup and directly consume from the src and that's what I'd recommend by default. See kzbin.info/www/bejne/emqnaX6Em8useM0 and how we don't export a precompiled ".js" file, but rather the ".ts" file directly. Precompiling most often makes only sense if you don't change it as often and therefore you can benefit from the presence of caching or if you want to publish these libraries and therefore need a dedicated build step etc. The "watch-deps" command is just there to help in those situations. You shouldn't need it by default :)

[@alebarrera1991]

I'd say just use Deno. Way simpler.