RFC: Introduce Analog application builder/dev-server

[brandonroberts]

Which scope/s are relevant/related to the feature request?

platform

Information

We've been discussing whether to pivot Analog more towards Angular tooling because the Angular team doesn't have any plans that I know of to support Vite in an "Angular as a Vite plugin" type of way, so there's always going to be friction there in the way the Angular CLI approaches tooling (no config access) vs Analog (Access to config + plugins)

Some notes:

One side:

• We get the benefits of Angular tooling + Analog DX. We can still support Vitest through a builder.
• Nitro still works either way, could be turned into a builder
• We do things "The Angular Way"
• All current features would still be supported

Other side:

• We could lose "being powered by Vite" for both build and serve, and a bit of the ecosystem and composability of plugins.
• The Analog Vite plugin for Angular would still be usable for outside ecosystems (Astro, Qwik, Playwright, Vanilla Vite + Angular app) and moved to a standalone repo.
• Have to do a bit of work to port over to esbuild plugins (to support content routes, markdown)
• Filesystem-based routing works already through an esbuild plugin
• Still needs a custom builder to enable esbuild plugins like @analogjs/platform:application and @analogjs/platform:dev-server
• Still lose Angular i18n support, but maybe gets closer because we're using Angular tooling

Hybrid option:
A hybrid approach could to use Angular build tooling + Vite for build/serve and keep access to the Vite config for additional customization. The Angular CLI only uses Vite for the dev server, but we could still use it for dev/prod.

Describe any alternatives/workarounds you're currently using

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[Jordan-Hall]

Do it, you was the reason I stopped the pure vite plugin because of analog and your strong view to keep it close to angular in that regards! For it to succeed it can't stay like it is. I think do it so it can be use in esbulid, vite or any system drop the ngtc

[santoshyadavdev]

My 2 cents, As an angular developer, I dont care to having much access to the config, and most developers in Angular system dont care.

• My choice would be having an builder, i think it will make upgrades easy too, thats the advantage Angular CLI had, you can always expose/remove more config option using builder.
• Developers can still extend the builder provided by Analog and build on top of it if needed

Looking forward to what other amazing folks have to add here.

[marcus-sa]

I don't care about Angular's tooling either.

[goetzrobin]

I don't care about Angular's tooling either.

@marcus-sa could you help me understand if you mean that?
Are you suggesting that you don't care about integrating closer with Angular because you enjoy the current Vite based tooling?

Or are you saying that you don't care about Analog being driven by Vite or more integrated with Angular as long as you can use what it provides right now: File-based routing, SSR with Nitro, server routes with Nitro, Markdown support?

[ocombe]

Well, you know my point of vue since we bootstrapped the idea together 🙂
I prefer to stay close to Angular tools because they spend a lot of time working on performance and additional features. If you go full vite, you lose access to that, there's no way you can compete, and you'll always be swimming against the current to keep your stuff working with their changes.
It's also easier for people to jump into an alternative builder if they don't need to change anything else (like the structure of their app).
Personally, I think that as long as we get nitro + vitest, it's perfect.

But I have no experience with Vite plugins outside of what I saw in analog, so I'm not sure if we would lose much there... What kind of plugins would be applicable to Angular?
In any case, I'm sure that the Angular team will end up embracing Vite plugins at some point, maybe in a year or so (it's definitely not a priority for them right now).

[brandonroberts]

Well, you know my point of vue since we bootstrapped the idea together 🙂 I prefer to stay close to Angular tools because they spend a lot of time working on performance and additional features. If you go full vite, you lose access to that, there's no way you can compete, and you'll always be swimming against the current to keep your stuff working with their changes. It's also easier for people to jump into an alternative builder if they don't need to change anything else (like the structure of their app). Personally, I think that as long as we get nitro + vitest, it's perfect.

But I have no experience with Vite plugins outside of what I saw in analog, so I'm not sure if we would lose much there... What kind of plugins would be applicable to Angular? In any case, I'm sure that the Angular team will end up embracing Vite plugins at some point, maybe in a year or so (it's definitely not a priority for them right now).

• Yes, I do 🙂
• Nitro and Vitest is already possible
• Vite plugins open up lots of possibilities. This is proven by how the Analog Vite Plugin enables Angular component usage within Astro, Qwik, Playwright, and other places. Even projects like Vanilla Extract are possible to use within Angular which is something that isn't supported by the CLI directly. Just about every major framework except for Next.js is embracing Vite and using it and allowing access to their ecosystem. It's part of why this project exists.

Glad to be proven wrong, but I personally don't foresee the Angular team embracing Vite plugins because they aren't using Vite for production builds, but esbuild. esbuild is plenty fast, and Vite is a means to an end for a development server in this case. They could have rolled their own dev server setup honestly. Plus they don't want you to care about the build tool/config unless you're a power user, and at that point, you're probably using a custom builder.

[luishcastroc]

i guess if the Idea is to be a meta-framework for Angular it just make sense to try to be as close as possible from the source, however there's huge adoption for Vite and everything it offers so that would be the tradeoff i guess.

[sand4rt]

because the Angular team doesn't have any plans that I know of to support Vite in an "Angular as a Vite plugin" type of way

Wonder if we could get more info on this? An official Angular Vite plugin will unlock a lot of doors :/

CC: @alxhub, @AleksanderBodurri (not sure who else to tag)
related: microsoft/playwright#27783 (comment)

[MitchSmoot]

Vite is definitely one of the big selling points of Analog for me. There's going to be a high-effort option to just support both and deal with the friction, and if we stick it out long enough I think the workload can be spread out between more contributors as this project gains steam. I think the Angular team sees Analog as a crucial future pillar that will hold up the Angular Renaissance, perhaps this project could over time influence them more towards vite support.

But I am insufficiently educated as to what kinds of effort this all entails. the Hybrid option seems good to me, but Overall, I believe we should take whichever option, sticking out the consequences, will lead to the most impressive 1.0 release. I bet the Angular team will be more inclined to work with us after 1.0 on whichever vite integrations will move Analog, and by extension the Angular Ecosystem forward.

[brandonroberts]

Great points @MitchSmoot and I agree with you. We've invested enough with the Vite integrations to move forward with them for the 1.0. I think the Vite integrations will help to move Analog forward more than creating a slightly different copy of the Angular builders. Some people will want everything built into the framework so they can/will use that, and that's ok.

[brandonroberts]

We've launched the 1.0 and may revisit this in the form of making Analog functionality available to Angular applications with a custom esbuild builder