[Epic] Common template features for .NET templates (sln, editorconfig)

mikadumont commented 3 years ago

Audience: template authors

Background

At the moment a lot of .NET project templates have to manually create similar configuration related to:

framework
restore post action
optional adding of sln
language-specific features
nullable, global usings and other common MSBuild properties
AOT configurations
NuGet Packaging Properties (license, package name, authors, etc)

Moreover more common features will be nice to have:

optional editorconfig (original intention of the issue)
optional gitignore/gitattributes; git init

Implementing all of above is possible but will result in extra ~300 lines configuration in template.json and corresponding testing and maintenance effort. The configuration will be very similar to the same in all the templates.

Technical suggestion

We are considering to create a specific generator for .NET project templates which implicitly supports the features above. All the author needs to do is to opt-in to desired behaviors via corresponding feature flags.

Justification

facilitate much easier entry point for template authoring via simpler configuration
decrease manual json configuration
unify configuration for the items above
unify experience with .NET SDK template

original description below Copying Kathleen's comments from below:

The template team maintains the .NET standard .editorconfig. Logically this is the same one you get with dotnet new .editorconfig. Templates will not include .editorconfig. When the user creates a project, they have the option to use --sln to create the project in a solution (a different feature that this assumes, although it might be later). If this switch is used, a .editorconfig will be placed at the solution level. If the user either creates the new project with a parent directory that has a .sln file, or they use the --sln switch, no .editorconfig will be placed in the project file. Otherwise, it will be. This might be managed by a post action so template authors could skip it, but we think it is probably the best behavior for all project templates.

The part about -sln is probably not relevant. Therefore, it should be considered out of the scope of this issue.

DavidKarlas commented 3 years ago

Can you share a bit more details what are you expecting here? Do you expect dotnet new editorconfig like https://github.com/dotnet/templating/issues/3195 suggests or you expect dotnet new console to include .editorconfig file?

mikadumont commented 3 years ago

Both but my issue is with regards to dotnet new console to include .editorconfig file (.NET) template which has the prepopulated default .NET code style, formatting, and naming conventions: https://docs.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project

KathleenDollard commented 3 years ago

@mikadumont @jmarolf and I chatted on this. It would be a nightmare to keep all the .editorconfig's consistent if we put them into every template, and then it would be a bad experience for users to wind up with multiple editor config's (per project) instead of one (per repo). That said, we love .editorconfig and want it in every repo :-) Thus, a new more complex feature!

A rough outline:

The template team maintains the .NET standard .editorconfig. Logically this is the same one you get with dotnet new .editorconfig. Templates will not include .editorconfig.
When the user creates a project, they have the option to use --sln to create the project in a solution (a different feature that this assumes, although it might be later). If this switch is used, a .editorconfig will be placed at the solution level.
If the user either creates the new project with a parent directory that has a .sln file, or they use the --sln switch, no .editorconfig will be placed in the project file. Otherwise, it will be.
This might be managed by a post action so template authors could skip it, but we think it is probably the best behavior for all project templates.

terrajobst commented 3 years ago

This sounds like another scenario where something like dotnet new repo would be useful…

bekir-ozturk commented 3 years ago

The details of the design can be found here (internal).

dotnet / templating