Is it ready for use?

[romeerez]

I'm trying out nx and I'm totally confused.

First thing, "integrated" vs "packaged" - docs provide no idea of what's the difference, which one to use when.
I tried both and seems like "integrated" bundles packages into the common "dist" on the top level, I guess this is the difference - you get a combined dist of all packages with the "integrated".

Installation, in the bottom:

nx generate application

It took me a while to understand that this requires installing "@nx/node" to work, there is no mention in the docs about this.

The generator script warns that from the 18th version, it will put new packages on the top level, which is weird. No other monorepo tools have projects on top-level AFAIK.

After installing "@nx/node", I could generate "app", but have no idea what it means, and why is it so: no package.json, "my-app-e2e" aside from the app with separate configs, again, I don't see any explanations in the docs.

I generated an app, how to start it? I've guessed by "project.json" that it's "nx serve my-app", but there is no readme, and there is no clue in the docs. Running nx test my-app errors with "can't find jsdom", okay removing it from vite.config. It's weird that the newly generated my-app has jest.config and no tests, and there is my-app-e2e with vitest. Looks like it's configured so that I cannot have any tests inside "my-app", only in "my-app-e2e".

nx is generating tons of files and makes so many patches, but with zero comments, it's frustrating that there are so many configs in your project that you don't know why they exist. For example, the generated eslintrc.json has three override groups for files with different extensions, and empty rules. I guess it's doing nothing, but why it was added then? A simple comment would help. You can write comments in eslint json, and in tsconfig json.

What is the difference between generating @nx/js:lib and @nx/node:lib? js one asks which test frameworks and which bundler to use, node one doesn't ask, produces no package.json, why it exists then?

As a bonus, the auto-suggested Idea plugin for NX is crushing regularly.

So my impression is that nx is not ready for use yet, it's confusing, instead of simplifying things it adds its complexity on top, docs cover only a small portion and the rest must be guessed by the user. The idea is still great, and the ability to scaffold projects is a killer feature that other mono repo tools like turborepo don't have, if only you could make it simpler, fix weird stuff, and document it properly it would be awesome. I'm wondering why this wasn't done in so many years.

Or maybe it's a skill issue, and nx isn't meant to be picked up quickly?

[moatorres]

Frankly, I think you either didn't fully read the documentation or you're feeling overwhelmed by the amount of configuration required to maintain feature-rich monorepos. At its most basic, you can hop into a "normal" repository, run "nx init" and configure it to use Nx. It would generate basic nx.json and project.json files, and update scripts to leverage Nx task execution.

I'll try to cover most of your questions anyway. I've been overwhelmed by it in the past and I can understand where you're coming from.

Integrated vs. Packaged
Mostly differentiate between how scripts are executed and how much they rely on Nx. Integrated uses nx plugins (@nx/node, @nx/react, etc) to run commands and lets Nx figure out dependencies by inference. It allow us to have package.json-free libraries and applications more reliant on project.json files. Packaged are on the more traditional spectrum, where each "module" (library or application) has its own package.json. Dependencies can either be managed manually, per module, or similarly to tools like Lerna and yarn workspaces.

Regarding generators, what you may be missing is that, at its core, nx is a hashing, caching and file system interaction mechanism. You could potentially use it to manage any set of files and programatically cache its outputs. That's the smart part of it. The fast part comes from the fact that nx uses Rust behind the scenes, which can be more efficient than Node.js/C++ bindings (that's also what SWC, Bun and others do).

Then there's the concept of nx plugins. That's the extensible part of it. @nx/node, for example, contains a set of functions that allow us to programatically generate applications or libraries, and execute scripts, but you could use @nx-go/nx-go plugin to generate, test, build and run Go applications.

The generator warn regarding Nx 18 top-level feature is there to let you know that iff you don't specify a location, Nx will create libraries and applications in the root directory. This is actually a good thing, since older versions didn't support that, and I'm not sure if other monorepo tools do.

I will not explain what an "app" is, but I'm pretty sure the docs explain why you may not need a package.json file. Look for the concepts of workspace libraries and buildable libraries. You'd also benefit by reading about executors and generators.

So my impression is that you're not ready to use nx yet. And that's ok. Nx wasn't born to scaffold applications in the sense that create-react-app does. The fact that nx plugins allow us to scaffold any application is a killer feature, but above everything Nx is a Smart, Fast, and Extensible Build System.

I understand how overwhelming it can be having to deal with all its files. Most of us didn't even use eslintrc.json on every single project, and I'm guessing that they come "empty" because it's up to us to add rules to our projects. Thanks to Nx we don't have to spend time boilerplating them.

PS: Nx is used on critical systems by 50% of Fortune500 companies. "Is it ready for use?" is a bit of an understatement.

[romeerez]

Integrated vs Packages.
What are the pros and cons, when to use which? No answer in your comment, or in the docs.

You're saying they are different at how they execute scripts, but if we compare "integrated" @nx/node:lib with "package-based" @nx/js:lib we'll see they are handling script executing in the same way. The latter is "package-based" because it generates package.json.

Regarding generators, what you may be missing is that, at its core, nx is a hashing, caching and file system interaction mechanism.

No, I'm not missing implementation details, I'm a user who wants to use it and had specific complains about the generators.

which can be more efficient than Node.js/C++ bindings (that's also what SWC, Bun and others do).

It's marketing, I didn't ask about speed, and there won't be any proof of Nx being faster than SWC, Bun, or others. This repo shows Rust 1.1% btw. Prisma also doesn't use Node-API for its Rust server, and it doesn't make it faster.

The generator warn ... is actually a good thing

I thought it's a bad thing, but thanks for letting me know it's a good thing.

I'm pretty sure the docs explain why you may not need a package.json file. Look for the concepts of workspace libraries and buildable libraries. You'd also benefit by reading about executors and generators.

Nope, the docs don't explain it. There is no concept of "workspace library" - no such phrase in the docs. I read about executors and generators, but it doesn't address any of my questions.

I'll try to cover most of your questions anyway.

Thank you for your time, but you didn't answer any of my questions.

I was wondering how big companies can use Nx when the docs and tools are what they are. But the business model explains everything, docs are lacking on purpose.

[moatorres]

Sorry, those are different questions. Here's a list of useful links that may or may not address your questions:

https://nx.dev/concepts/integrated-vs-package-based
https://blog.nrwl.io/build-your-design-system-with-storybook-nx-e3bde4087ad8#:~:text=Nx%20libraries%20are%20%E2%80%9Cworkspace%E2%80%9D%20libraries,json.

Good luck.