Simple Command line Project Helper (Would love feedback)

• EasyCLI

  1 1 10.0 C#

• CliFx

  7 1,421 8.2 C#

  Class-first framework for building command-line interfaces

Is there any reason why I would use this over established projects like CliFx or CommandLineUtils?

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• CommandDotNet

  3 550 5.9 C#

  A modern framework for building modern CLI apps

Have you seen https://github.com/bilal-fazlani/commanddotnet? Disclaimer: I'm one of the maintainers What you've thrown together does seem similar to CliFx in some respects, as you mentioned in another thread. It looks like a command must be defined as a class. I once created a framework that followed that approach and ultimately found it limiting. I've found it to be more expressive to use methods to define commands, although both are possible with CommandDotNet. For example, we can use the position of parameters in the methods to define the position in the command. Defining operands (positional parameters) via properties, we automatically position them based on position in the file, which was interesting because .net does not guarantee order of properties when reflecting them. We were able to use CallerLineNumber to get this. You might look into that. To answer the question of `Is the use of the project simple and have any benefit over using other parsers?` I'd say that CommandDotNet, CliFx, Spectre and even MS's System.CommandLine have a head start on tackling some of the more complex features and already have some community around them. It think this project has a bit of catchup to do. For example, you can see the CommandDotNet features at https://commanddotnet.bilal-fazlani.com/features/ A lot of the design went into making it a simple as possible to define a command using c# conventions, like parameter positions, NRT, optional parameters, etc. Fore example, we use nullability to determine if an argument is required, although it's also possible to use DataAnnotations or FluentValidations to perform more complex validations. That all takes a bit of time to support. I'd say if you're looking to experiment and play around, keep at it. It's unlikely you're going to get a lot traction in the space though, especially since MS has their own framework. If you want to contribute code that's more likely to be used and seen by others, look at System.CommandLine or one of the other main tools. If you continue with this one, feel free to use CommandDotNet for reference if you'd like hit me up for questions on the discussions, or feel free to bring ideas to CommandDotNet and contribute.

Suggest a related project