Why was Nx removed?

[svallory]

Hi! I know this is not directly related to the project, but I was watching a video where @ixahmedxi was showing how Nx was used in the noodle project.

I went looking for that video after facing a LOT of issues trying to set up Nx with proper typescript compilation (including project references) and svelte.

I was surprised to see that, as far as I can tell, noddle isn't using Nx anymore and, since I was already thinking about not using nx due to all the problems I've had, I would deeply appreciate it if any contributor could tell me why that is. That would really help me decide whether to use nx or not.

Also, @ixahmedxi, if you have any addendum for the video, of things you learned or issues you faced with the package-based approach, I would love to hear

[ixahmedxi]

Hello @svallory firstly, thanks for watching my video with the NX team. I love NX, its an essential tool for me whenever I have a monorepo.

So here the difference is monorepo and not nx, if Noodle was still a monorepo, NX would be there.

The change from a monorepo to a normal nextjs singular application setup came from the understanding of my needs with the project.

I was initially thinking very much far ahead when Noodle will need multiple applications, publishing packages, design system...etc and that came with a lot of cost in terms of maintenance of this setup. Noodle doesn't actually need to be a monorepo right now, it will need to be in the far future but when we get to that requirement then the added complexity of the project setup is justified.

I have changed my approach on monorepos over the past few months, and I now advocate for going towards a monorepo approach when it's clear that you will need multiple applications or publishing packages. Otherwise purely for code organisation it doesn't make sense because just stick it in a folder in your src and you will be good. The added complexity without a clear advantage of a monorepo setup basically just doesn't make sense.

I would actually advocate for a singular repo when you only need one application, after that NX integrated monorepo because with plugins you won't need to maintain the configuration and after that if you have a specific requirement to manage your config by yourself then think about package based monorepos.

I hope this helps with your decision, if you do still need a package based monorepo example look back a few commits behind its still there :)

[svallory]

Firstly, thanks a lot for taking the time to reply!

That was a tremendous help! I see your point and agree with everything you said. I thought separating parts of the code in libraries to control boundaries would be really easy with nx, but I quickly ran into issues due to the poor support for Svelte.

I'm creating a Figma plugin and I need to ensure complete separation between the UI and the plugin's main thread and they both depend on a shared lib. UI and main libs must be compiled separately, both to single IIFE style JS files. On top of that, we had to create supporting packages we want to publish on NPM: pure ECMAScript (so they run inside Figma) test runner, message bus, and RPC library.

It's been kind of a nightmare to get that working with Nx (and I've tried different build options).

Am I finding this hard because I'm new to Nx or is it actually way out of Nx's paved path? If the latter, would you proceed with trying to use Nx?

[svallory]

Btw, the fact that there are 41 typescript compilation bugs with the oldest opened since June 2020 and several bugs open since mid-2022 has me very concerned I may paint myself into a corner