Invoking dotnet scaffold in an empty directory

[jaliyaudagedara]

Ask a question

Right now when we do dotnet scaffold from a directory that doesn't contain a .NET project, we can interact with the tool, but nothing happens which of course makes sense as there is no .NET project.

In this case, should we throw an error message instead of letting users interact with the tool blindly? Because it's not a valid context for the tool.

[tlmii]

Because it's not a valid context for the tool.

I would say that it is not a valid context for the current set of scaffolders rather than for the tool itself. A future scaffolder could very well work with an empty directory.

I think we can still find a way to message this better to the user, but we want to make sure not to block future valid scenarios.

[jaliyaudagedara]

Yeah, I agree. If there is a plan to move dotnet new functionality to dotnet scaffold, it perfectly makes sense for those. If the scaffolders requires an existing project, then would be great if we can message the user when a project is not present.

[deepchoudhery]

I think the one change I could potentially see here is that if we have a REQUIRED option (--project for the current set of scaffolders for example), we could exit out of the interactive loop messaging to the user that no options were found the required option 'Project File' (whatever the appropriate display name is). For not required options, there is a 'None' option in the list to skip past it. The experience currently with showing the empty list there is not too bad in my opinion since there is a very simple way to leave the loop. And it should be pretty self explanatory that no appropriate options were found but I am open to adding the simple messaging suggested above. Thoughts @tlmii @jaliyaudagedara

[tlmii]

Yeah, I agree. If there is a plan to move dotnet new functionality to dotnet scaffold, it perfectly makes sense for those. If the scaffolders requires an existing project, then would be great if we can message the user when a project is not present.

Not sure I'd say "move dotnet new functionality" so much as just "dotnet-scaffold is flexible, so scaffolding could be used for a lot of different reasons."

I think the one change I could potentially see here is that if we have a REQUIRED option (--project for the current set of scaffolders for example), we could exit out of the interactive loop messaging to the user that no options were found the required option 'Project File' (whatever the appropriate display name is). For not required options, there is a 'None' option in the list to skip past it. The experience currently with showing the empty list there is not too bad in my opinion since there is a very simple way to leave the loop. And it should be pretty self explanatory that no appropriate options were found but I am open to adding the simple messaging suggested above. Thoughts @tlmii @jaliyaudagedara

Definitely agree that we could make the experience of selecting projects better (both when there are none and when there are too many - like when you accidentally execute it in the root of your dev drive). Probably something to get the PMs in on.

A problem we run into is that we can't really fast-fail here. We need to let the scaffolders themselves decide. We could maybe allow scaffolders to expose a property that says "allow empty folder"? And if all of them say false we fail fast before even allowing the user to select a scaffolder? But do we really want to special case empty folder that way? What about "no projects in descendant folders"? Or when we get to implementing the capability detectors?