search

Tyrrrz / CliFx

Class-first framework for building command-line interfaces
MIT License
1.5k stars 61 forks source link

Ensure that user's commands don't have conflicts with built-in options #37

Closed Tyrrrz closed 4 years ago

Tyrrrz commented 4 years ago

Command types should not contain options that resolve to one of the built-in options, i.e. --help/-h and --version (only on default command).

Currently this is not validated and will lead to undefined behavior (built-in options take precedence but both kind of options will still appear in help text).

Need to add validation and corresponding tests.

Tyrrrz commented 4 years ago

Remember to add corresponding analyzers.

Tyrrrz commented 4 years ago

Actually, it would probably be better to let user create options such as -h/--help or --version but then make it so that their default behavior is cancelled. That way it's still up to the user if they want to override it or not. Maybe it's worth adding a hint through analyzers in such cases (not sure if that's possible).

Tyrrrz commented 4 years ago

Another thought, I think it's better to come up with a better design for built-in options, so that they are part of the command schema from the start. This way this issue is "fixed" automatically by the duplicate name/shortname rule.

domn1995 commented 4 years ago

What about adding the help and version options as properties in the ICommand interface as default implementations?

In essence,

public interface ICommand
{
   [CommandOption("help", 'h', Description = "Shows help text.")]
   public bool HelpOption { get; set; } = false;

   [CommandOption("version", Description = "Shows version information.")]
   public bool VersionOption { get; set; } = false;

   ValueTask ExecuteAsync(IConsole console);
}

Users who wish to override their implementation may do so on a per-command basis.

Tyrrrz commented 4 years ago

I thought about it. The problem is that VersionOption only exists on the default command.