Open vlada-shubina opened 2 years ago
I like how explicit -group
and -identity
options are. At the same time, I think this may result in too much typing.
For instance, to instantiate editorconfig template from Boxed.Templates, one would need to type:
dotnet new editorconfig --identity Dotnet.Boxed.editorconfig.CSharp
which is much longer compared to
dotnet new editorconfig
The same happens with --group
option.
Maybe as an alternative, we can add a postfix to conflicting short names. For instance, if you have two templates with short name editorconfig
, one could be renamed to editorconfig2
. Numbers could be added according to the alphanumeric ordering of template package identifiers. If you delete/update template packages, the ordering and hence the short names may change.
Another option would be to support the template identity as the main parameter to dotnet new
, in addition to the template short name. This would allow for a greater degree of specificity and not have the duplication inherent in the dotnet new <template short name> --identity <template identity>
example. One downside here is that the template identity may not be unique enough, or in some cases may be the same as the short name, so better tools for template authors to detect and fix these scenarios might be required.
One downside here is that the template identity may not be unique enough, or in some cases may be the same as the short name, so better tools for template authors to detect and fix these scenarios might be required.
Template authors shouldn't be doing this. Instead of working around it, let's error when a user tries to install a template with a conflict on identity
.
I can run my template analyzer to see if there are any duplicate IDs being used. I'll try to do that soon. I'm currently in the middle of some changes so I may need to wrap that up before hand.
Here is a JSON file (renamed as .txt to support GH) with all the templates that I could find. Will look for dupes later. template-report.json.txt
I ran my tool to identify templates that re-use the identity
value across templates.
I only found 4 IDs that are actually being used in different templates.
template-pack-id identity
Microsoft.DotNet.Web.ItemTemplates Microsoft.Web.Grpc.Protobuf
Microsoft.DotNet.Web.ItemTemplates.6.0 Microsoft.Web.Grpc.Protobuf
VijayAnand.BlazorTemplates VijayAnand.WindowsForms.Blazor
VijayAnand.BlazorTemplates VijayAnand.Wpf.Blazor
My report did include the following as well, but that is due to this bug https://github.com/dotnet/templating/issues/4140. Those are listed below.
template-pack-id identity
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowFeature
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowConfiguration
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowPlusProfile
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Project
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowFeature
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowConfiguration
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Item.SpecFlowPlusProfile
SpecFlow.Templates.DotNet SpecFlowTemplates.DotNET.Project
Threenine.ApiProject Threenine.ApiProject
Threenine.ApiProject Threenine.ApiProject
VijayAnand.Wpf.Blazor VijayAnand.Wpf.Blazor
VijayAnand.WindowsForms.Blazor VijayAnand.WindowsForms.Blazor
Laconic.AppTemplate Laconic.AppTemplate
Laconic.AppTemplate Laconic.AppTemplate
VijayAnand.BlazorTemplates VijayAnand.WindowsForms.Blazor
VijayAnand.BlazorTemplates VijayAnand.Wpf.Blazor
E5R.Architecture.Template E5R.Architecture.Template.FullSolution
E5R.Architecture.Template E5R.Architecture.Template.FullSolution
sayedha.templates Sayedha.Templates.CliTool
sayedha.templates Sayedha.Templates.IdeHostJson
sayedha.templates Sayedha.Templates.TemplateJson
sayedha.templates Sayedha.Templates.TemplatePackJson
sayedha.templates Sayedha.Templates.CliTool
sayedha.templates Sayedha.Templates.IdeHostJson
sayedha.templates Sayedha.Templates.TemplateJson
sayedha.templates Sayedha.Templates.TemplatePackJson
There are three sides to this:
Pack
ing a template, we could check against the search json for duplicate identity
ies to help the user not upload garbage data. Probably default this to not run when Deterministic
is true
, because we don't want to do network I/O on reproducible builds--force
flag similar to our other overrides on installation (e.g. the updated package templates override we added recently)For the Authoring
case, I think this should be a warning and not an error.
At the moment 2 cases for ambiguity may happen during template instantiation:
Those cases may be solved by uninstalling one of the packages in template groups are coming from different packages, however if they are coming from single one the situation cannot be resolved.
Suggesting the following options to resolve these conflicts:
--group
allows to specify group identity to run--identity
allows to specify template identity to runUnable to resolve the template, these templates matched your input:
To run specific template, specify its group using --group option.
dotnet new short --group Group.Identity1.
Unable to resolve the template, these templates matched your input:
This may happen due to authoring error or ambiguous parameter set
.To run specific template, specify the identity using --identity option.
dotnet new short --identity Templ.Identity1