Preserving SPA tool chains (e.g. Angular CLI)

[smoses2]

I know several asked how to specifically integrate angular CLI into the template:
2/14 blog announcement. It has also been mentioned as part of other issue threads on GitHub (#97).

I use Angular CLI and asp.net core, and really like the idea of these templates integrating the asp client-server and the associated tooling you've developed. But removing the spa/client native tooling such as Angular CLI is a deal breaker for me. I do not use React/Redux, but I would imagine there may be similar issues.

I have seen several options for this, and I like the idea of this 2 project solution:
Angular2 CLI with ASP.NET Core application - tutorial

Here, the asp.net core backend has one project, and the spa frontend another. The build process for the spa frontend writes distribution to the wwwroot folder of the asp.net core application.

Currently, the template is not useful to me other than a demo. In the future, I hope these templates can be my starter projects, once they leverage the SPA framework functionality, while still facilitating asp.net core - spa integration/build/CI.

[ADefWebserver]

Is there a specific task that you can do in Angular-CLI that you cannot do when using JavaScriptServices?

[smoses2]

Yes.

1. Code generation for components, directives, pipes, services, routing... It automates creation of associated files for each of these: html, ts, css/less/sass, unit tests. It automates module and routing creation.
2. Optimization. Here there there is likely overlap (e.g. AOT) with what javascriptservices can do, but will it's tree shaking and other optimization be as effective as that written by the SPA framework dedicated team? As they change their framework, will your tooling lag significantly?
3. Unit testing and E2E commands could be run directly from node instead

[ADefWebserver]

1.Code generation for components, directives, pipes, services, routing... It automates creation of associated files for each of these: html, ts, css/less/sass, unit tests. It automates module and routing creation.

I want that too.

My hope is that JavaScriptServices is just the first step for Microsoft to integrate all that into Visual Studio. Customers such as myself do not want to drop to the command line. We want to operate completely inside Visual Studio using visual tools.

[MarkPieszak]

This was already discussed in #828, and I definitely understand the desire for it, but the problem remains if you want any sort of Server rendering with the CLI (even if just node itself) you normally need to eject the webpack config, which in turn makes it no longer a CLI based project, it's possible to do it without ejecting it, but then you'd need to concurrently start multiple processes (one to spin up the client, one for a node server), not sure how that would work with .NET (?)
Anyway, so we'd probably need to eject it as well, so we'd be in the same position we are now with our own webpack configurations etc.

Of course if you don't want server rendering, then you're all set with a project setup above that splits them between 2 projects and outputs the dist into the .NET project! 👍

As for ^1 : you can just add an angular-CLI.json file to get generators working.
#828 (comment)

^2: even with an ejected webpack config you're either only going to get a prod one or a development one, it depends on how you ejected it, so either way we would need some complex webpack configuration to get the best of both worlds. You can see I'm working on it here, and I have SEO, Angular 4.0, AoT, but there is still some optimization and cleanup that needs to be done. Not an easy task.

^3: unit testing is already built into the repo, e2e could be added just as easily, it's just protractor.

Although in theory it'd be great, the reality is that the CLI is its own entity, and in that way, it actually hides the user from all the files and configuration, but when you're talking about integrating it with another framework, you actually need everything exposed (ejected) and that's unfortunately why i don't think it'll work.

---

As for staying completely within the IDE, I imagine buttons/extensions could be scripted fairly easily that just invoke the command line commands for you. Although I'd recommend just getting used to command line, pretty much everything involves it now (for better or worse) 😷

Anyway just wanted to give some insight into everything at least from the Angular point of view, I can have another talk with the CLI folks, but I'm pretty sure it'll be the same situation (eject everything).

[smoses2]

Thank you Mark - great answer. I am sorry I did not see #828 before. I especially appreciated the explanation on adding the angular-CLI.json file to get generators working. Did not know you could do that.

As for server side rendering, for most of my use scenarios, the angular built-in AOT should be sufficient, and that should not require any server side node/compilation after the production build is created. I like having the eject option for customizations I cannot get working, but most of my projects would continue with CLI.

I can see the attraction of combining the api and the SPA in one project, single IDE with a single build. It's a natural transition from asp.net MVC.

I love VS for C# code for server side and desktop. I want core templates that set me up for best server practice - integrating identity (e.g. identity server) and database... I want the template to give me a place for my automation to plop in my client side compiled app, while automating the server infrastructure around it.

But for client side, VS has always seemed slower and fragile. TS and LESS compilations sometimes break and I need to restart VS. javascript testing also works better for me outside VS. Instead, I typically use VSCode with a couple of ps windows open. I want to be able to run/test this app disconnected from the asp.net core api.

Isn't it hard to maintain all of javascript services for multiple different SPAs. If you created a core api - SPA template that was generic ("your js tooling to copy code here") - then wouldn't the template be easier to maintain? You would defer all the SPA specific management to the frameworks (angular, react) and concentrate on putting all the hard-to-integrate server pieces together and expose them easily to the client (e.g. Identity).

[SteveSandersonMS]

Thanks for the discussion. I'll close this as I think all the points have been addressed both here and in earlier issues.

For people who prefer to separate their ASP.NET site and their SPA site, that's absolutely fine - it's a totally valid arrangement. The templates in this repo are for people who want a single integrated site that can be deployed atomically, feels like working on just a single app, etc., which means taking more of an ASP.NET-centric approach.

[maxisam]

Now AngularCLI 1.3.0 support Universal, aka server side rendering. I wonder if we should revisit this issue.