Here is an Aurelia CLI, .net core 2.0 MVC, webpack template.
dotnet new -i Designs.Digital.Aurelia.Templates.MVC
This will install the ‘dotnet new’ template. After installation it can be used as follows:
dotnet new au-net -n Site -ow "Bob" -t "Test Site"
au-net
is the name of the template -n Site
an arbitrary name for the project, -ow "Bob"
and -t "Test Site"
are just test values that are replaced in the ‘Loading…’ string.
For more information: dotnet new au-net --help
Since I am using Windows 10 the following is an example for that platform. The equivalent for other platforms should work. To get an Aurelia CLI, MVC core, webpack site running in one go:
- Create an empty directory to place your project.
- Open a shell to that directory.
- Run or paste the following:
dotnet new -i Designs.Digital.Aurelia.Templates.MVC
dotnet new au-net -n Site -ow "Bob" -t "Test Site"
cd site
yarn install
au run
The template will be installed, site generated, build and run. Simply open a browser at http://localhost:8080
to view (or check console output for url).
So, why?
I was looking at the Aurelia CLI and how it generated sites from the user input. I was thinking about the possibility of having templates accessable via the CLI but external to it. This may allow easier maintenance and creation of more templates?
I couldn’t find a repo for the template… Would you accept a PR?
I did not upload a repo for the template as it was only intended as a conversation starter. I could do this though. I think having a series of CLI compatible templates external to the CLI itself makes sense from a maintenance perspective? Did you find a specific issue?
Getting people from zero to up and running quickly, understandably and without issue is vital initial positive experience and to adoption. My own initial CLI experience forced me to apply fixes to get up and running. Regardless of the reasons this should not be the case.
Funny enough, a couple of days ago I posted a link to another dotnet+webpack skeleton.
The issue I’ve found is bloated app bundle. In my opinion, it’s better to split based on a module path, not manually. Have a look at the config in this https://github.com/MaximBalaganskiy/AureliaDotnetTemplate
The template itself is Aurelia CLI generated with one or two fixes related to this.
When I revisited Aurelia CLI a few weeks ago I found multiple issues preventing me from just getting up and running. To be fair most of these seem to be dependency related, though, it is the responsibility of the project to manage what is referenced and how in my opinion. When I took a look at the CLI source I saw how the templates were generated and thought maybe it would be better to have template source external to the CLI. The CLI could use these as opposed to generating templates internally using conditionals.
I believe the template you provided is more of a minimal starting point rather than a CLI template?
@MaximBalaganskiy & @constructor
would you guys be able to work on this in aurelia-contrib?
@Alexander-Taran You know my predisposition towards CLI I would be happy to change ownership of the template
I would be willing to contribute, but I do not know how useful the contributions would be without further understanding the nature of the CLI and how others use it. Most of the changes here are from my perspective only, along with some ideas based on personal experience.