Create ASP.NET Core Aurelia Template for dotnet new

[chrisckc]

I'm submitting a feature request

Create ASP.NET Core Aurelia Template for dotnet new in favour of the Aurelia CLI generated dotnet template.

The ASP.NET Core Aurelia Template was retired in dotnet v2.0. currently, out of the box, dotnet new no longer provides an Aurelia template.

This issue has been created to continue the discussion which was born out of this issue: https://github.com/aurelia/cli/issues/979

Which resulted in the intention to create a custom dotnet new template for Aurelia: https://docs.microsoft.com/en-us/dotnet/core/tools/custom-templates

Current behavior: The Aurelia CLI creates an outdated ASP.NET Core template.

• What is the expected behavior? There needs to be an up to date ASP.NET Core template available for Aurelia as is the case for other SPA frameworks. The template should contain some basic code demonstrating the use of the framework with ASP.NET Core as is the case for the other SPA frameworks.

• What is the motivation / use case for changing the behavior? Help Aurelia gain traction as a front-end framework in the huge .NET developer community.

[chrisckc]

It would make sense to use source files from the skeleton repo in the dotnet new generated template.

@EisenbergEffect do you know any details of how the skeleton source will be integrated into the CLI, is the source to be embedded and maintained in the CLI or to be pulled down from the 'skeleton-navigation' GitHub Repo?

It would make sense to keep the the skeleton source in its current repo so that it can easily be maintained and used in both the Aurelia CLI and the 'dotnet new' template. An additional folder could be created in the skeleton repo such as 'skeleton-typescript-webpack-aspnetcore' this could be used by the dotnet template generator (assuming this is possible)

This way users would also have a choice of either using the CLI for generating standalone Aurelia templates, using the 'dotnet new' template or cloning any of the projects in the skeleton repo. To align the experience, the 'skeleton-typescript-webpack-aspnetcore' project should use the same webpack config and project structure as generated by the 'dotnet new' template. The same should apply for the Aurelia CLI generated templates.

This would also make it easier to upgrade existing projects to align them with future versions of the 'dotnet new' template in terms of webpack config etc. as configs can just be compared to the repo. There will obviously be an overhead in keeping configs in the skeleton repo up to date with CLI / 'dotnet new' generated configs.

[EisenbergEffect]

@chrisckc Sorry for taking so long to respond to the question. I got backed up on issues :) I really appreciate your dedication and partnership in working on this.

Our plan for the CLI was to keep the source internal to it, in a resources folder. However, there will be a new CLI command that will generate all the skeleton projects. We could use this to generate out the content for the dotnet new template as well, I believe. So, the skeleton repos themselves will basically be generated from the CLI. The work is almost ready, I believe @JeroenVinke can comment on that status and whether he thinks this scenario can also be handled by what he's been working on in the CLI.

[JeroenVinke]

The skeleton feature is done, @jwx is just making the final changes to it.

I have not worked with the dotnet generator. We’d have to know what options are available to us.

As Rob said, we keep the source files inside a folder in the cli. When the new au generate-skeletons is executed we create projects using various options (ts, babel, webpack, the internal cli bundler etc).

All those project folders will then be pushes to the skeleton navigation repository.

In the current dotnet workflow you first do a dotnet new followed by au new. We have some logic in the cli to determine what files already exist (like an index.html) and we prompt the user when that happens.

Ideally, a dotnet new command is enough. The new skeletons don’t require you to install the aurelia cli, and it would be great if that isn’t necessary for dotnet new either.

I think we need to know what options are provided to us by the generator and go from there

[chrisckc]

@JeroenVinke Thanks for the info, i see that work has already been done in your CLI feature to enable the generation of a dotnet project.

All those project folders will then be pushes to the skeleton navigation repository.

So the skeleton navigation repository will be kept up to date with the CLI generated code?

In the current dotnet workflow you first do a dotnet new followed by au new. We have some logic in the cli to determine what files already exist (like an index.html) and we prompt the user when that happens.

With the current workflow that you have developed, what kind of dotnet new templates are supported for adding Aurelia using the CLI? (eg. mvc, web, razor, webapi)

In what way does au new modify the dotnet project, does it configure it using the SpaProxy method inline with the way the dotnet Angular template now works?

Going forward, is it actually worth creating a dotnet new template for Aurelia seeing as a solution has already been developed?

The Aurelia CLI would still be a good thing to have in order to run the webpack dev server and build the app bundle etc. I know that npm commands could be used instead.

In the Microsoft Angular template, the Angular CLI is required, it is installed by the template generator , the user is warned if they do not have Node installed.

I suppose the question to ask is this: Is it easier to maintain a dotnet new template or the Aurelia CLI to modify a dotnet new generated project to add Aurelia?

[EisenbergEffect]

Our approach to the skeletons is basically to have the CLI generate all the skeletons and then publish those as a release of the skeleton repo on GitHub. Could we just have the CLI generate the files and then copy those over into the asp.net template, and finally publish the template in the same way? How hard it is to create a template?

[chrisckc]

That should work as there doesn't need to be anything special about the Aurelia project when using the new dotnet SpaProxy method. A standard Aurelia CLI generated webpack project with https://github.com/aurelia/cli/pull/982 merged in will work fine.

The Aurelia project that sits inside the ClientApp dir in the dotnet project is will not be tied back to the dotnet project in any way like it is in the current Aurelia CLI generated dotnet project, It can be separated at any time as is the case with the dotnet new angular template.

Creating a custom template looks quite simple, it just a matter of creating the working project as required and then adding a template configuration file. The contents of the project are then used to create a NuGet package which can be installed into 'dotnet new'. The NuGet package would then need to be published to NuGet under an Aurelia official package name/namespace ideally.

I will be able to use the Angular template files to create the project as it is very similar, i have already done this in my repo here: https://github.com/chrisckc/DotNetCoreAureliaSPA (the webpack config used there is out of date compared to my other repos). The Readme inside the 'dotnetcore21-spa' dir details what was required to convert it to Aurelia.

I should get around to doing some work on this in coming week. I will need a GitHub repo which i can use for the project which is to be used in the template.

It might be better to have the 'dotnet new' generated project use the Aurelia CLI from NPM to generate the contents of the ClientApp dir. Promoting the use of the CLI in the dotnet new generated project is good thing?

This approach would also require less maintenance as it would remove the requirement to update the dotnet template every time the CLI is updated. It should be possible by plugging additional build commands into the dotnet project file so that the ClientApp dir is created on first run if it does not exist. Currently in the Angular template is just checks for Node and then runs 'npm install'

[EisenbergEffect]

I like this approach. I'll review #982 and see if we can get that in. If you want to work on this in your own repo, and then post a link when it's ready, we can review and determine if we need to create a new repo here or if we should add it to an existing repo, such as the skeleton repo.

[chrisckc]

@EisenbergEffect Just putting something together, is there a way to use the au new command non-interactively? The help only shows a single option "--here".

I wanted to have dotnet create the Aurelia project inside ClientApp on first run if does not exist. Instead it will have to show an error message stating that au new needs to be ran.

This should be acceptable though, the Angular template shows an error is Node is not installed, the Aurelia template will also require that the CLI is installed globally and au new is ran, with error messages indicating such.

[chrisckc]

It would be great if the CLI could be ran fully automated with an option to specify "Default TypeScript" as the type of project to create.

In theory the user should be able to choose any of the available options in au new when creating the project, the only one that needs to be avoided is:

What platform are you targeting? "2. ASP.NET Core"

That option will need to be removed before the template is made available to avoid any confusion.

The question "What is your default code editor?" won't matter much. The generated project is inside a subfolder, so in the case of VSCode for example, the generated .vscode settings won't be used unless the subfolder is also opened directly in addition to the dotnet project, which is a valid and useful dev scenario.

In order to make this work Aurelia project creation

[chrisckc]

I also notice that the dotnet angular template is built to use NPM because it forms part of the publishing command which performs npm install before the angular build. The Aurelia CLI asks if "Yarn" should be used, this will cause issues unless the .csproj file is edited to change the publishing commands.

[chrisckc]

I have noticed that Yarn is the default when going through the CLI's custom creation path, i also noticed that when using the "--here" option, the CLI no longer no longer asks to create the default project, it skips straight into the custom path.

I wanted to prompt the user to run au new --here from within the ClientApp dir rather than run au new from the dotnet project root and have to tell the user to make sure they choose "ClientApp' as the project name. This also ties in nicely with the message that appears after au project creation, as au run will work without having to cd into the 'ClientApp' dir

Ideally it should be able to be auto created on first build using CLI options, with a readme in the dotnet project stating that a custom project can be created instead if required by running au new before the first project build.

It looks like to make this template a reality will required a PR or two on the CLI first.

[EisenbergEffect]

We can make whatever customizations in the CLI that we need to make this a smooth experience for .NET. For example, we could create a custom workflow.json for the .NET CLI case and then add a command that lets you invoke the Aurelia CLI with the custom workflow. We're open to adding new features that would make this smooth for .NET developers. Let us know what you think would work best.

[raupes]

Feedback: Its really hard to get started with aurelia and .net core. It really would be cool to get the used usability with a project template at visual studio (like available for react or angular - heart bleeding for missing aurelia here). I think it would be great for getting more visibility to aurelia having a up to date project template at vs.

Although after figuring out to use dotnet new and then au run --here and then usedotnet run and also au run(what doesn't work because of some things I couldn't find out so far) is not the best user experience. Aurelia is a really great framework to work with. But if - and only if - you can get it run.

[veikkoeeva]

@chrisckc This and the other issues really are a admirable load of work. The very least I could do is to get you coffee if I knew how!

This is exactly the kind of stuff I have been slowly working on (this is mostly an evening hobby for me currently). My angle was more from https://philipwalton.com/articles/deploying-es2015-code-in-production-today/ as wanting to not to transpile on module supporting browsers and then the rest -- and split approriately. But enough of that. I want to bring up https://natemcmaster.com/blog/2018/07/05/aspnetcore-hmr/, the MSBuild .target files at the end of the blog just in case they provide useful ideas.

[milkshakeuk]

@chrisckc any news / updates on this?

[veikkoeeva]

@milkshakeuk Some of the ideas have made their way to the current setup, I think. I did some ad hoc experiments with going further, noted at https://github.com/aurelia/cli/pull/1067#issuecomment-485676282.

[milkshakeuk]

@EisenbergEffect can this be closed as we have Aurelia DotNet Tooling however that repo seems a bit stale, is it being actively maintained?

[EisenbergEffect]

@brandonseydel Can you chime in here on the status of the arelia/dotnet repo and how you see that integrating with CLI, etc.? Thanks!