mirror of
https://github.com/aspnet/JavaScriptServices.git
synced 2025-12-23 01:58:29 +00:00
Add new Angular CLI-based template #412
Assignees
fergalmoran
Clear assignees
fergalmoran
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github/JavaScriptServices#412
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SteveSandersonMS on 9/19/2017
The Angular template shipped with .NET Core 2.0 originated well before
@angular/clicame on to the scene. Even when@angular/cliwas 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/clisuch 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/clirather 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 angulartemplate to use a newSpaServicesfeature 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 calledClientApp, but now when the browser makes requests for content under/dist, we will pass through the request to an instance of@angular/cli'sng serveprocess. As such, the output and behaviour will be identical to what you'd get if you ranng servedirectly, and all the same config and features apply. If you wanted, you could even take yourClientAppdirectory out of your project and run it manually withng serve, since it's literally just a standard@angular/cliproject. Likewise you canng ejectit 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 publishcommand (or the Visual Studio equivalent option) would not only publish the .NET part but would also automate the process of usingng 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
SpaServicespackage 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
BuildServerSideRendererflag in csprojng serveprocess 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.scriptinpackage.json(in which case, make the task name appear explicitly in the C# source so people can discover what it does).npmchild processes aren't left behind on exit, including when usingdotnet watch, including on Mac/Linuxpackage.jsonandnode_modulesat project root (is this necessary for VS to do auto-restore?). If so, need to support findingnode_modulesin ancestor directories usingrequire-from-string-type approach (#154), since Angular app will be in subdirectory. Update: Not doing this - it's impractical. Angular CLI is hardcoded to assumenode_modulesis in the project root (e.g., seegetBrowserConfiginmodels\webpack-configs\browser.jsline 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.csprojcontaining instructions to do the applicablenpm installin theClientAppsubdir during build when necessary.index.htmlto be a server-rendered cshtml page instead. Update: Not supporting this. Doesn't really make sense.<base href>matches thePathBaseof the incoming request, and if not, fail with a clear message. Alternatives include rewritingindex.htmldynamically to inject a<base href>based on the per-requestPathBase, or just rely on people reading docs to know they have to configure this manually before publishing.package.jsonshould be there)Pre-preview (try it)
You can now try this out. For instructions, please see https://github.com/aspnet/JavaScriptServices/issues/1288#issuecomment-346003334