Rework @nx/js and @nx/node for consistency and clarity

[LongLiveCHIEF]

Discuss: Is a rework of @nx/js and @nx/node needed?

Problem As I see it

These two plugins seem to have overlapping functionality and purpose.

It appears that over time, the scope of @nx/js and @nx/node has become somewhat intermixed, to the point where there is now a confusing set of options for both users, and for developers looking to use the generators and executors as base compositions for local or publishable nx plugins.

Feature state of both combined plugins

• @nx/js only generates libs, whereas @nx/node will generate both libs and apps
• @nx/js has a node executor for running node apps, but can't generate node apps
• @nx/node can't use tsc bundler/compiler
• @nx/node library generator can use the tsc bundler

User and plugin author experience

• @nx/js can build and run node applications, but it can't generate them
• @nx/node can't generate tsc applications even though it can generate tsc libraries
• there is currently a "native" gap between these two plugins such that you can't generate an application is built with tsc and run with node (only application generator is nx/node and it doesn't support tsc bundler)
• generators for both @nx/js and @nx/node appear to intend to support the same concepts in terms of testing/bundling/compling/linting/etc... but they're not kept up to date with each other
• @nx/node uses @nx/esbuild, establishing the pattern of externalizing the "builder" executor with generated node apps, but the @nx/js/typescript executor is internal and at times has proven to be tightly coupled to the "library" type even though the "typescript" build experience is greatly desired for typescript server applications

Thoughts and Solutions?

I could easily submit PR's to add the tsc functionality to the @nx/node application generator options, but then I think that would just further add to the problem of these two plugins having overlapping scope and creating a confusing user experience.

I think it would be better to take the time now to create a clear scope and purpose for all of the javascript/node/bun plugins in the core of nx. Each plugin should have a clear scope. Perhaps @nx/js limits responsibility to compilation, and then there could be a plugin for each of the javascript runtimes.

Maybe there's another solution or scope, or perhaps the solution is to combine @nx/node and @nx/js and eliminate one or the other entirely?

[LongLiveCHIEF]

I've also been looking for a good was to begin contributing to this project, and if I could get some directional support from the Nx core team, I feel like this is work I'd love to contribute with.

I know these two plugins are integrated quite a bit throughout the internal and the larger community ecosystem, so anything in this line of work would definitely be slated for the next major version of Nx, but I feel like solving the scope problem of the javascript oriented plugins in the core of nx could be extremely beneficial to Nx in the long run.

At this point, I'd probably vote in favor of deprecating the @nx/node plugin entirely, and just adding an application generator to @nx/js.