Difference between CommandDotNet and Spectre.Console

[lonix1]

New user here - I've read the docs and am very impressed.

I noticed that CommandDotNet uses Spectre.Console.

Does someone know how they differ? I initially assumed Spectre.Console is only for formatting text, but its docs show it also handles commands, arguments, etc. (the stuff this library does).

Do I need to use both, or can I use Spectre.Console only? Will I miss out on any features if I do that?

[drewburlingame]

Hi @lonix1 and welcome.

Thanks for the compliments.

You do not need to use Spectr to use CommandDotNet. We've integrated with them to make their AnsiConsole available as a command parameter and to integrate that with our test framework. That is the only point of integration with them.

My preference, and obviously I'm biased, is to use CommandDotNet to define my commands and bring in Spectr when I can benefit from their superb table layout or prompt tools.

[drewburlingame]

In terms of what features you'd miss out on, it would take a while to do a full comparison, but some of the answer depends on what you'd use. CommandDotNet has a lot of features that I don't use on every project but are very helpful when I do need them.

I think defining commands is a lot less effort with CommandDotNet because you don't need to inherit from a class, commands can be defined with methods and you are not forced to define arguments in other classes. So for getting a simple command app up and running, it is much less plumbing with CommandDotNet.

We also have a lot less issues. Scrolling through Spectre issues, you can see a lot of issues for things that just work in CommandDotNet. Some of that can be attributed to Spectre being more popular and thus more edge cases are encountered. I believe some of that is the level of testing we've done from the API layer. We have over 1K tests covering our features and so we catch regressions quickly. We're also very stable so we don't have the code churn to introduce regressions. Our architecture makes it simpler to observe SOLID principals like open/closed so new features are less likely to touch code for existing features.

[lonix1]

Thanks for the explanation.

From what little I understand so far, it seems that the basics - commands, arguments, etc. - exist in both libraries, but since that is the whole point of this library, it does all that in much more detail. (Whereas Spectre does formatting in more detail, hence its inclusion in this library.)

And from what I understand from your comment (and saw in the docs) this library has lots test-related stuff, which I won't find in Spectre.

So unless I want to recreate the wheel (I don't), I'm better off using this library, with Spectre under the hood.