RFC: Switch to Nx for create-analog package

[brandonroberts]

We are basically maintaining two separate templating systems at this point. Idea. What do you think about switching create-analog to basically be a wrapper around:

npx create-nx-workspace --preset=@analogjs/platform

Pros

• Simplifies maintenance
• Takes advantage of standalone Nx CLI project.json structure for Angular apps
• Works the same inside/outside of Nx monorepo

Potential Cons

• It would move us off the Angular CLI and angular.json
• Lose ng update, ng add

Update:
Nx allows you to create your own CLI that can do both

Originally posted by @brandonroberts in #388 (comment)

[mihajm]

I'm probably only going to use analog with nx so functionally it's pure benefit. But if it were in a work project, id be cautious of a coupling to a non-strictly-necessary dependency :)

[brandonroberts]

I'm probably only going to use analog with nx so functionally it's pure benefit. But if it were in a work project, id be cautious of a coupling to a non-strictly-necessary dependency :)

Which is the non-strictly-necessary dependency? Nx?

[luishcastroc]

I would probably embrace NX if the focus of Analog will be to be as versatile as possible, if the idea is the framework to be used in both simple and large projects NX is for sure the best for it's extensibility.

[justinrassier]

I am a bit of an Nx fan, so I am biased, but I say the upsides of embracing Nx would outweigh the downsides for sure.

[mihajm]

I'm probably only going to use analog with nx so functionally it's pure benefit. But if it were in a work project, id be cautious of a coupling to a non-strictly-necessary dependency :)

Which is the non-strictly-necessary dependency? Nx?

Yup nx :) the way I see it as an angular meta-framework that one is very obviously required whereas nx as a monorepo tool is an addition to the stack that benefits dx but might not be what the user wants, especially if alternatives such as turborepo take off.

I could be misunderstanding the original question tho & as said, love nx myself and will pretty much always use it for analog/angular projects :)

[ErickRodrCodes]

I would like to see this happening. Nx is robust enough to handle the needed generators for the analog package for it to happen. you got +1 on it.

[dalenguyen]

+1

Nx would help to offload a lot of maintenance work if this means Analogjs will reuse Nx infrastructure.

[Hazzajenko]

100% nx

[stianmorsund]

I personally think Nx is superior, and have been using it alongside Angular almost since it’s inception.

I do however understand if the project doesn’t want to couple itself completely to Nx (as mentioned earlier in the thread) and potentially exclude some users

[rainerhahnekamp]

I wouldn't do it.

If Analog only works with Nx-powered Angular applications, I'm afraid that some potential users might be locked out.

Having nx as a development dependency is a different story, though.

[brandonroberts]

I wouldn't do it.

If Analog only works with Nx-powered Angular applications, I'm afraid that some potential users might be locked out.

Having nx as a development dependency is a different story, though.

I agree. I still want to support both workspace styles. This would still allow you to use an Angular CLI workspace setup as an option. We would just be using Nx underneath to scaffold the application and run the initial setup options for standalone projects and Nx workspaces.

[brandonroberts]

Going to close this for now as we'll keep the standalone template generator and look at using Project Crystal for Nx workspaces