OmniSharp / generator-aspnet

yo generator for ASP.NET Core
877 stars 168 forks source link

Creating classes in child directory #632

Closed stuartleeks closed 5 years ago

stuartleeks commented 8 years ago

Short issue description

Specifying a path in the class name generates the file in the correct location, but the Class name includes the path and slashes

Expected behavior

Class name of "Foo\Bar" results in a class named "Bar" in the "Foo" directory

Actual behavior

Class name of "Foo\Bar" results in a class named "Foo\Bar" in the "Foo" directory

Steps to reproduce the behavior

yo aspnet:Class Foo\Bar

OS version (Win/Mac/*Nix?)

Win10

NodeJS version

4.2.1

Yeoman version

1.7.0

Generator version

0.0.93

peterblazejewicz commented 8 years ago

@stuartleeks Why this should be treated as expected behavior? That's not part of other Yo's generator UX pattern. That works in VSCode or Atom but is not a common in generators I believe. Thanks!

stuartleeks commented 8 years ago

@peterblazejewicz What do you see as the expected behaviour? Or do you not see specifying a path in the class name as part of the defined behaviour?

The current behaviour allows you to enter a path, but the result is broken, i.e. fails to compile. The suggestion is to make a small change to this scenario that would result in working output.

Would there be any negative impact of making this scenario work?

peterblazejewicz commented 8 years ago

OK. I believe we could use Node mkdirp or fs-extras for this: https://github.com/jprichardson/node-fs-extra#mkdirsdir-callback https://www.npmjs.com/package/mkdirp The namespace support is already in place, but directory/directories creation support is not available. Can be post RC2?

stuartleeks commented 8 years ago

I've had a stab at implementing this - I look forward to your comments :-) #635

peterblazejewicz commented 8 years ago

@stuartleeks It cannot be ad-hoc single purpose solution, we use sub-generators for named items that extend Yo Named generator. We have to find a solution that ties both default yo solution for application names and current custom solution in generator that supports namespaces. It should be done once for all subgenerators that are based on named generator (The Class item generator is only one of them). I agree it is useful UX pattern to add - even if supported only in VSCode (I cannot use it in Atom/Sublime on Mac OS X). I'd leave it open for discussion and start work on this after RC2 is matured and released.

lukefan6 commented 8 years ago

Hi guys I have related question so I guess I'll just ask it here.

I'd like to have similar experience in vs2015 where I can create a new class in specified child directory and the generated class would have both its namespace and name configured as what you expect in vs2015.

For example, if my default namespace is "MyNamespace" and I enter this

yo aspnet:class Builders/Test

I expect a Test.cs in Builders folder and its content like:

namespace MyNamespace.Builders
{
    public class Test
   {
   }
} 

As far as I can tell from this thread, you guys are figuring the class name part out but I'd like to know if it's possible to take the namespace part into consideration too so we can have consistent experience like we are using vs2015, thanks.

peterblazejewicz commented 8 years ago

@lukefan6

I'd like to have similar experience in vs2015 where I can create a new class in specified child directory and the generated class would have both its namespace and name configured as what you expect in vs2015.

This can be achieved with extensions for IDE of your choice. For example for VSCode: https://github.com/jchannon/csharpextensions

There is no clear definition what is a project and this generator uses assumption that a directory with a project.json (if found) constitutes a C# project. Another assumption is that generator adds its own meta to project.json with namespace. All of this are assumptions, so the simple solution is only implemented: assuming you're in the directory where content is to be created the tool will generated relevant class (or just a file) from template preserving namespace and correct nesting. No other implementation exists. As the things are now in accelerated flux as the MS is migrating things from project.json to xml-based configuration (not all details are yet public or documented somewhere), I'd not invest a time at the moment to implement additional features like one you've mentioned. Hence try with extension I linked, it should be exactly the thing you're looking for.

lukefan6 commented 8 years ago

@peterblazejewicz got it, thanks for the explanation.

sayedihashimi commented 5 years ago

We are shutting this repo down, it's been replaced with dotnet new.