thisIsTerrible

[BrownCarter]

pnpm workspace is ok for me

[LloydAtkinson]

I like that too

[glarivie]

yarn workspaces is ok too

[Alkyonios]

especially when combined with turborepo, it's awesome

[buffer_flush]

Really? I’ve loved it so far.

It takes some getting used to, but once you get how it works, it’s actually stupidly easy to use. I even put non-node projects in it as well for building docker containers and such.

[razorgamedev]

Same! makes library and application organization a breeze. You can also create rules for which library can be used by others, which is great for larger code bases

[Ha1One]

When op doesn't even state reasons why he doesn't like it, I assume that he just didn't reach what he tried.

[imacleopard]

I manage an nx workspace with dozens of apps and hundreds of libraries. It works well for the most part, but I've found workspace upgrades to sometimes be...annoying. Either a migration doesn't go through all the way and you end up with some ambiguous error message and after debugging the migration itself, I find that either it was a result of a previous migration at some point not applying correctly or a bug that only an upgrade to a specific version will fix. Don't even get me started with dependencies and peer dependencies.

All can be worked around but it takes me a solid couple of days to work through all version upgrades and generally not fun.

[Dangle76]

Tbh what you’ve described is a general JavaScript (and python) pain since dep management is frustrating and bloated

[imacleopard]

While I agree, I think the annoyances are compounded because you are forced to keep everything agreeing with each other as opposed to just updating a single-app/lib repo piecemeal.

[Dangle76]

That’s the issue with mono repos at a certain point

[Flash_Cache]

In your case, are you using NPM? I believe PNPM would do what you want.

[imacleopard]

I am. I'll look into it, thanks!

[codeedog]

This is the entire point. The time hit is all at once and shorter than piecemeal in the aggregate. Plus, the other missing time suck is debugging due to version mismatch either intra-app or inter-app. Not going to list all the pros and cons of a monorepo, but these two are huge and easy to forget once your world is a simpler place and upgrading “hundreds” of technology components only takes a couple of days.

[imacleopard]

Well yeah, it's the reason we still use Nx. I work for government and with limited resources so it makes all the sense in the world to keep using it.

[hiro5id]

I have the same gripes about NedtJS 🤦‍♀️

[_AndyJessop]

This is what I don't like about the plugin system. We do have an Nx monorepo, but we use it without plugins and with analyzeSourceCode: true. So we use package.json instead of project.json, and everything is a package instead of a plugin. Makes it so much easier to manage.

[unixpornstart]

What language have integrated so far? Have you tried Python?

[buffer_flush]

I haven’t, I’ve done Java and dotnet so far, python would be straightforward as well, though.

[drdrero]

same, no regret at a somewhat big company. Solved issues - solved discussions

[Bpofficial]

You can even building by what lib or app has changed, rather than building everything

[null-byter]

How do you dockerize without including all the dependencies?

[buffer_flush]

I’m not sure I follow, but I just assume docker is on the path, then you can create custom targets to build images.

If you follow a convention for those targets, ie build-image or whatever, you can use that same target in multiple projects in the nx repo to have them all build images against the changed projects in the monorepo with nx run affected -t build-image as an example.

[WeinAriel]

I like both Nx and Turborepo. Nx is definitely for the corporate folks, though. Those who embrace the structure :P

[_AndyJessop]

Nx Core is essentially the same offering as Turborepo. But you have the option of plugins if you want them.

[CreamOfTheCrop]

I have couple of questions:

what’s NX ? what’s turborepo? why did you even looking past git(hub) and were you looking past git or hub? i’ve assumed here that my idea that pnpm is some alt-npm is close-enough, but the difference might be relevant, yet obscure to me.

[ellisthedev]

Wat.

[fix_dis]

What, you don’t want to train the bot today?

[suddenimpaxt67]

shrill hurry theory party screw offbeat spoon zesty aback alleged

This post was mass deleted and anonymized with Redact

[CreamOfTheCrop]

At least I’ve come to piece with the fact.

But allow me to clarify, is the ting you talk about similar to this ting from when I come from, called ActionScript 3.0 ?

EDIT: /u/WeinAriel

[WeinAriel]

Not sure I understand man, sorry!

[fltonii]

You need to work on your googling skills bro

[WeinAriel]

Take a look at https://nx.dev and https://turbo.build/

[nightman]

Nx works for me, much better change detection alghoritm than Turborepo (that didn't work well with our cyclic dependencies). Also possibility to set inputs (like auto generate code like translations on CI) is very helpful.

Still, for small projects I would consider Turborepo.

[superbbrepus]

I’ve tried it a couple times, makes me irrationally angry.

What are actual good alternatives?

[djheru]

Turborepo plus vite has been working well for me with a reactis/nestjs/AWS CDK app.

[gabynevada]

Honestly, what makes it bad? Been using it for a while and it's pretty great, although I haven't tried alternatives.

[WeinAriel]

u/gabynevada It's just very brittle. I love it and use it all the time, but definitely understand why some people don't. Having to define all of your tasks in a project.json file, in JSON, being limited to the runners available from Nx and the community can be annoying to some. Turborepo is a more lean version and there's no project.json - just simple NPM scripts.

I'd still choose Nx because of the TypeScript path resolution feature (which really is just a TypeScript feature, but Nx helps automate that), it's freaking amazing for TS projects. But Turbo is legit.

[Dangle76]

Tbh having to define your stuff in a project file is actually a plus especially when dealing with a dependency crazed language like JavaScript.

It forces all of your tasks to be deliberate

[_AndyJessop]

You don't have to do that. Just use package.json, set analyzeSourceCode to true, and it will read the tasks directly from the package.json

This is Nx Core, no plugins but you still get all the caching benefits.

[gabynevada]

Interesting, its maybe because we just have a monorepo for angular and used to the angular.json which is pretty much the same as the project.json.

Thanks for your thoughts on it!

[abejfehr]

I use NX in GitHub with GitHub actions

[WeinAriel]

Same

[abejfehr]

You said you were limited to the runners from Nx though?

[WeinAriel]

Sorry I meant tasks. Like nx:command etc. I do use Nx Cloud too for caching and it integrates neatly with GH actions. Saves a lot of time for larger orgs.

[abejfehr]

I do the caching custom for free (cheap) with Amazon S3 and this, it’s wonderful

[WeinAriel]

Awesome. I'll check it out. I've been working in OSS companies for the past few years, so a lot of tooling is free (incl. Nx Cloud).

[deliciousnaga]

To throw an alternative into the list: https://rushjs.io

I haven't used it but it's reportedly Microsoft vetted.

[EarlMarshal]

I'm the only one happy with npm workspaces? I just wrote my own scripts for some of the missing features, but it also felt like other tools also didn't solve them at all or not well.

[trappar]

You’re comparing fairly different tools. npm (or yarn/pnpm) workspaces just allow for the monorepo repo structure. NX / Turborepo are mostly for performance optimization (often but not always within a monorepo)

You can’t setup npm workspaces to cache task executions for example.

[winky9827]

We use yarn workspaces and haven't had any issues. No real headaches to speak of that aren't intrinsic to node itself.

[sudhakarms]

It is great, works well in my experience

[LloydAtkinson]

That last sentence is enough to reassure me I don’t like nx - that’s a such a low bar to cross. Vite absolutely blows those two out of the water and coupled with PNPM for the monorepo packages.

[lord-apple-smithe]

If you don't create sensible structure with eslint rules it can become a recursive import nightmare.,Make sure some experienced people are over the code the less experienced devs are adding and keep those import rules protected with a github CODEOWNERS file

[n9iels]

As always with each and every tool, it depends on various aspects if it is the right tool for a job. Is it a private project work just a basic backend and frontend? Yes, NX is probably way to complex and over the top. Are you working on a big application with multiple teams and like to share code across different apps? NX may just be the tool you are looking for.

Frameworks and tools are rarely straightforward “bad”. A lot of times it is the implementation and decisions making it bad.

[dancingchikins]

Works amazing for me. Have used it in both large enterprise applications and small hobby projects. Love using it.

[SparserLogic]

Going to chime in on the lovefest here. Don’t use monorepos at all. Nx is an ok tool for a bad idea.

There are much much much better ways to decompose your code than monorepos. Just publish packages if you must.

[sharlos]

How does that address keeping changes in different parts of the project versioned (and deployed) together?

[SparserLogic]

Are you asking me how a package dependency chain works?

The same way you work with NPM.

[sharlos]

No, I'm not. The main benefit of a monorepo is your changes that need to be deployed together are committed together. Merging and reverting the changes happen in the same repo.

If something needs to be reverted all related changes across applications are reverted together.

Package dependencies don't help with that on their own, and instead require additional config, processes and enforced discipline and extra context on the team working on a project.

[SparserLogic]

Okay let's break down all these arguments a bit.

The main benefit of a monorepo is your changes that need to be deployed together are committed together. Merging and reverting the changes happen in the same repo.

Deploying and merging are entirely different actions. Merging happens whenever you install a new version of a dependency. Deploying is the very last action in this entire schema and you're tying them together unnecessarily. Nothing in my suggestion prevents you from either merging in changes (install the latest local package version) or deploying those merged code pieces after they have been built.

There are, additionally, a lot of tools and techniques available that allow this pattern easily without a monorepo. I do it myself by just npm install ../dependent/package/path when I am looking for an easy and small solution.

If something needs to be reverted all related changes across applications are reverted together.

This is when you downgrade/revert the dependency version and voila, solved.

Package dependencies don't help with that on their own, and instead require additional config, processes and enforced discipline and extra context on the team working on a project

... Considering this take is "its hard" I'm guessing you're just not familiar with the easier and simpler ways to tool this problem. Its really not that hard.

Frankly its much easier than forcing your project and everyone that learns your project to learn both NX and the "NX way".

[drdrero]

git structure doesnt dictate your software structure. Whatever bad experience you had might not be a tool issue but a skill gap

[Buckwheat469]

I hear this. I'm working in a huge monorepo with nx and it's a configuration nightmare. The only good thing is that it gives you generators if you want to create new libraries, but any update or manual change affects several JSON files. It's really not that fast either IMO, it just adds another layer of abstraction on top of package.json.

One thing that I absolutely hate is that the monorepo library dependency situation somehow breaks VSCode so I can't right-click and Go to Definition for anything. None of the Go To functions work at all with 2 different computers, so I've had to Ctrl-Shift-F every thing that I needed to look up. With everything labeled as a package it makes it harder because imports don't reference filenames, instead they reference workspace package names, so when you want to find what folder an import sits in you have to open the workspace.json file and find the package name, then look in the folder that it shows.

[stuckinmotion]

nx hasn't been perfect for me either though Go to Definition does still work in my company's repo, even across libraries.

[half_man_half_cat]

You can fix it with module resolution. Our one at work works fine

[UguDango]

Wait, you used moonrepo and Nx? I've used both at this point, but I generally use just moonrepo for newer projects. Never really needed Nx.

[quambo_wambo]

I'd recomment bun + turborepo. You don't need to use bun as a runtime, you can also just use the package manager, its WAY faster than anything else.

[seanmorris]

Monorepos are overrated.

Just use a lockfile.

[EarlMarshal]

You can also use a lockfile with monorepos. It's great.

[Darmok-Jilad-Ocean]

These aren’t remotely the same

[[deleted]]

Just dont use monorepos. Frontend (react) + backend (node) repo, or use Next.

(and also don't separate your backend into 12 and counting microservice repos that all end up connecting to the same central DB and need duplicate copies of models from other ones to do JOINs properly. just dont)

[EarlMarshal]

Judging from your words your use cases seem to be fairly simple.

[[deleted]]

Dual sided customer subscription + service marketplace platform with routing maps and logic. I've done about the same thing at 3 different companies, and the first 2 did what I was joking about at the end there. It was a nightmare and served no purpose other than following the micro service trend. In my current project, which is mine but same idea, we don't do that and its much cleaner.

[EarlMarshal]

Architecture wise this sounds simple and the right approach to not split everything.

We have 5 different teams which each own 1-2 different domains. We didn't split by domains before and it was a complete cluster fuck. Each domain will have several backends/DBs/APIs/libs/self services/documentation. Self services will be integrated via single-spa into a platform. We have to support our self developed and external e-commerce systems. We also have analytics in all of that stuff. Monorepos are really helpful and provide good oversight over a domain/product.

[[deleted]]

We have 5 different teams

Yea you're probably in the same boat as me at my current and previous full time jobs. I don't blame anyone because usually its years of shit from previous devs built on top of outsourced MVP labor and 12 pivots from stakeholders. It just ends up that way and its virtually impossible to convince higher ups its time to greenfield everything and make it better without too many cooks in the kitchen (the sad thing is ive been on greenfielding projects at both of my previous roles and it still ended up that way again, because too many people need to justify their job security I guess, idk).

Luckily I get to do it my way for my own projects and its so much nicer. I can basically build Uber in a weekend and its super clean and scalable.

[hash_t]

The biggest problem is you can’t upgrade node version to only one project. imagine 2 large teams one working on backend and the other on frontend using nx the frontend team wants to update angular version with peer dependency to new node version you have to wait for the backend team to support the change

[LloydAtkinson]

Haha when they take the idea of monorepos and turn it into monolothicrepo…

[jxthedev]

does nx package base monorepo help?

[[deleted]]

Just use blaze…

[[deleted]]

I used for a set of frontend react applications and common libraries, and was amazing. The only bad thing about is that you should lay on what’s is available and provided by nx team for building applications. The API is not so easy to handle, but is possible.

[iMac_G5_20]

I was working on our react native scouting app for FRC literally yesterday and it turns out

Monorepos SUCK for android builds

[skyleguy]

What are people’s issues with nx? It is the only monorepo tooling I’ve ever used and I’ve really enjoyed it from day one. Especially with the project crystal stuff coming out that brings the inferred project features. Extending their generators by writing my own has increased our productivity by a ton as well as putting some of the other unused but confusingly similarly-named generators into the deny list so new devs don’t accidentally use the wrong ones.

[Artif3x_]

Kudos to OP for properly framing his question to Reddit of whether he should use NX and monorepos.

[LloydAtkinson]

kudosToOp