Add new Angular CLI-based template

[SteveSandersonMS]

The Angular template shipped with .NET Core 2.0 originated well before @angular/cli came on to the scene. Even when @angular/cli was first shipped, it was unclear whether it would become the de facto standard way to build real-world Angular apps. But now it seems the Angular community largely sees the CLI as the preferred approach, and it has stabilised and matured into something you actually can use in real-world development scenarios.

So, even though the ASP.NET Core Angular template has pretty much all the same features as @angular/cli such as HMR, AoT on publish, Karma tests, etc. (and in fact even some features that the CLI lacks, such as out-of-the-box server-side prerendering), it would be advantageous if our template achieved that stuff using @angular/cli rather than having its own implementation. The key benefit is that developers will have an even more typical project setup, so basically all online tutorials, StackOverflow posts, etc., will apply without any modification.

Approach

The idea is for an updated dotnet new angular template to use a new SpaServices feature called Angular CLI middleware instead of the existing Webpack middleware. So it will still be a single ASP.NET Core project with the Angular part in a subdirectory called ClientApp, but now when the browser makes requests for content under /dist, we will pass through the request to an instance of @angular/cli's ng serve process. As such, the output and behaviour will be identical to what you'd get if you ran ng serve directly, and all the same config and features apply. If you wanted, you could even take your ClientApp directory out of your project and run it manually with ng serve, since it's literally just a standard @angular/cli project. Likewise you can ng eject it if you don't want to use the Angular CLI for some reason (and then use Webpack middleware like before if you want).

Of course, because you then have a standard Angular CLI project, you can use all other CLI features such as ng generate, ng lint, etc., without anything being different just because you're also using ASP.NET.

We would also integrate with Angular CLI when you publish your app. That is, a single dotnet publish command (or the Visual Studio equivalent option) would not only publish the .NET part but would also automate the process of using ng build -prod, putting the output in the right places to be served in production. Likewise, server-side prerendering would also be achieved by a call into Angular CLI.

Note: This would not be a breaking change. The SpaServices package will continue to work exactly the same with existing applications created using the .NET Core 2.0.0 template - this scenario remains fully supported.

Tasks

• Add BuildServerSideRenderer flag in csproj
• Add new API for supplying custom data to prerenderer
• Support "proxy only" mode for AngularCliMiddleware, so you can have an ng serve process running separately and not restarted on each C# code change. Ideally, decouple the proxying from the Angular CLI-specific bits so it can be reused with other SPA frameworks.
• Consider whether it's practical to proxy the HMR endpoint. If not, this will be difficult to use from inside a Docker container (or at least requires extra configuration). Update: it does now proxy, so should work fine in Docker.
• Try to get CLI's progress display reflected in the console.
• Ensure that any errors occurring in angular-cli-middleware.js are passed back upstream. This also includes the CLI writing to stderr.
• Stop hard-coding CLI options in angular-cli-middleware.js. Either have a .NET API for configuring them, or better, call a script in package.json (in which case, make the task name appear explicitly in the C# source so people can discover what it does).
• Make sure the npm child processes aren't left behind on exit, including when using dotnet watch, including on Mac/Linux
• Get SSR working with publish by default. Waiting on Easy "ng build" improvements to make "platform":"server" work well on Windows & Visual Studio angular/angular-cli#7903
• Consider whether it's desirable to have package.json and node_modules at project root (is this necessary for VS to do auto-restore?). If so, need to support finding node_modules in ancestor directories using require-from-string-type approach (Resolve node modules in parent directories #154), since Angular app will be in subdirectory. Update: Not doing this - it's impractical. Angular CLI is hardcoded to assume node_modules is in the project root (e.g., see getBrowserConfig in models\webpack-configs\browser.js line 25), so we'd need to have the .NET project root as the Angular CLI project root, which means merging the folder structures (super ugly, and violates the intended separation), or having an extremely nonstandard Angular CLI config to have it fetch all sorts of things from a special subdirectory (violates the idea of it being a standard Angular CLI project). Instead, we'll rely on the .csproj containing instructions to do the applicable npm install in the ClientApp subdir during build when necessary.
• Figure out how the APIs would look if someone wanted index.html to be a server-rendered cshtml page instead. Update: Not supporting this. Doesn't really make sense.
• See if it's possible to detect efficiently whether the <base href> matches the PathBase of the incoming request, and if not, fail with a clear message. Alternatives include rewriting index.html dynamically to inject a <base href> based on the per-request PathBase, or just rely on people reading docs to know they have to configure this manually before publishing.
• Ensure the right set of files are appearing in VS's Solution Explorer (e.g., package.json should be there)
• Add shrinkwrap
• Fix the bootstrap nav button in the Angular templates (and check it works in the others)
• Ship preview

Pre-preview (try it)

You can now try this out. For instructions, please see #1288 (comment)

[RobertPaulson90]

Totally agree! I've been quite annoyed lately, fighting some CORS-related issues, I still cannot find a solution to (due to having both back- and front-end separated).
I would have loved to have them combined, for server-side-rendering too, but it was an intentional decision (which may seem detrimental now), to utilize the "mainstream" @angular/cli for boilerplate generation.

My "risk assessment" on trying to predict the future, says @angular/cli is likely a safer dependency in the long run.

I think the perfect scenario would be if dotnet new angular relied on the @angular/cli, as suggested, in such a way that you could at any time extract only the Angular project and continue using it only with @angular/cli. Is that feasible?

Google's Angular already relies on Microsoft's TypeScript - can the teams coordinate it so @angular/cli won't make unnecessary breaking changes so it's safe-ish to be embedded in JavaScriptServices :-) ? Or does it not work like that, lol. In any case, please take @SteveSandersonMS post very serious!

Of course, because you then have a standard Angular CLI project, you can use all other CLI features such as ng generate, ng lint, etc., without anything being different just because you're also using ASP.NET.

This would simply be amazing...

[peterdobson]

@amivit I don't have my back- and front-end in separate projects anymore but when I did, if I recall it was just a case of having:

  services.AddCors(options => options.AddPolicy("MyPolicy", p => p.AllowAnyOrigin()
                                                                      .AllowAnyMethod()
                                                                      .AllowAnyHeader()
                                                                    ));

.. in the right place in ConfigureServices() and:

app.UseCors("MyPolicy");

...in Configure()

[MarkPieszak]

@SteveSandersonMS We also have Universal support in the CLI now, but I'm wondering if we will be able to pipe that into aspnet somehow as well? Let me know if we can meet up again when you have some time I'd love to help anyway I can to merge the two processes, or help add any hooks Aspnet would need from the CLI.

This would be ideal in letting the CLI community handle all upcoming Angular aspects of the template as well, improvements, etc 👍

Exciting times!

[RobertPaulson90]

@peterdobson that works for anything except POST. POST is special since the Access-Control-Allow-Origin NEEDS an explicit reference to the requests Origin. So I made an explicit Origin which works fine for everything, except POST.
The issue occurs because browsers by design, strip the initial OPTIONS request of all headers (such as authorize).
For some stupid reason, my app when deployed to IIS, expects the Authorize even on the OPTIONS, and returns 401 unauthorized. If I enable anonymous access globally on the ng frontend, the problem goes away. Which is fine for this internal tool, when the API is still secure.
I guess it's more of an IIS issue, and I don't want to hijack this thread, which I'm already in the process of doing :/

aspnetcore-angular2-universal seems cool, but way too bleeding edge for me to dare use for anything production. I'd prefer relying on @angular/cli with asp.net/JavaScriptServices

[wangkanai]

@SteveSandersonMS Is this a plan feature or already release? Because choosing the angular template today would get the webpack middleware, which has many bug. Upgrading to bootstrap 4 took me the whole afternoon without success. Npm will not install bootstrap 4 in visual studio 2017 enterprise. So went to command line and did it, then SpaService would not webpack the bootstrap 4 into the bundle.
Just gave up in the end.

[jrmcdona]

@wangkanai it is not already released

[chencingyen]

@SteveSandersonMS this is that i've been waiting for :)
nice 👍

[spboyer]

This also solves questions around using environment variables/settings for client-side code.
https://github.com/angular/angular-cli/wiki/stories-application-environments

[SteveSandersonMS]

In case anyone wants to see, I'm working on this here: https://github.com/aspnet/templating/tree/stevesa/angular-cli-template. Don't ask for support with getting or using it yet though - it's not ready 😄

[naveedahmed1]

This would be awesome! The production builds through angular cli are also very well optimized and also includes features such as hash file name.

[jrmcdona]

@spboyer I could use that too. Had trouble getting it working well using the Angular CLI built in enviornments configs.

[smoses2]

Fantastic news. For the last year, I've been avoiding javascript services since as Steve notes at top of this issue, many of us prefer the angular cli. I have been building my angular 2/4 with angular CLI in its own project and writing to an asp.net core wwwroot directory for production. But this missed all the tooling you've developed around javascript services, made integrated testing slow and split the angular app from my development process for the Api/MVC and IdentityServer projects.

Looking forward to seeing what you do with exposing angular cli, while maintaining other javascript services tooling (outside webpack),and config for the enclosing asp.net core project. My greatest concern would be to not interfere with the angular upgrade process - i.e. when I update the package.json with angular 5..6..7, that the coupling to asp.net core and javascript services stays loose enough, that the breaks I need to fix are angular specific.