feat: Add 'charOnly' flag option

[childish-sambino]

This feature adds a new flag option (charOnly) which, when set, disables
support for the long version and does not report the long version when
displaying usage.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @childish-sambino to sign the Salesforce.com Contributor License Agreement.

[codecov]

Codecov Report

Merging #47 into master will increase coverage by 0.8%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #47     +/-   ##
=========================================
+ Coverage   90.21%   91.02%   +0.8%     
=========================================
  Files          11       11             
  Lines         327      323      -4     
  Branches       88       84      -4     
=========================================
- Hits          295      294      -1     
+ Misses         13       12      -1     
+ Partials       19       17      -2

Impacted Files	Coverage Δ
src/flags.ts	100% <ø> (ø)	⬆️
src/parse.ts	92.19% <100%> (+0.77%)	⬆️
src/index.ts	100% <100%> (ø)	⬆️
src/help.ts	77.77% <100%> (+5.55%)	⬆️
src/validate.ts	96.87% <0%> (+2.28%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b420f0f...646d865. Read the comment docs.

[jdx]

Can you explain why you would want only short flags? IMO this isn’t a good UX pattern

[dprothero]

Nice!

[childish-sambino]

@jdxcode Fair point. In this instance I'm trying to avoid conflicts between long versions. I.e., my core CLI may only use short version flags and all plugins use long version so as to avoid conflicts.

[dprothero]

@jdxcode All of our commands inherit from a common base command that introduce two standard flags. It was possible for plugins to duplicate these flags (particularly the dynamically generated commands from our Open API spec). Since they were global flags (and advanced usage patterns at that) we felt it was fine to use a single character for them.

The other option is to use a more verbose name, but we didn't like the UX of that either.

[childish-sambino]

@jdxcode And another option was to use pre-topic flags and post-topic flags, but that is a more opinionated solution and a more difficult implementation (I think).

[childish-sambino]

@jdxcode Is this something you're willing to support? If not, we'll need to figure out a reasonable alternative.

[childish-sambino]

@jdxcode Alternatively, I'm fine with allowing both short and long versions to be parsed, but help output only shows the short version.

[RasPhilCo]

@childish-sambino @dprothero After talking it over with @jdxcode, we don't think we should introduce this pattern, but we should provide help overrides (via a template pattern or such). That way you could hide long flags with a simple custom template override. Would that work for you all?

[childish-sambino]

@RasPhilCo That should work. Haven't looked into implementation yet.

[RasPhilCo]

I've added it to our backlog, but admittedly it may be a bit.

[childish-sambino]

@RasPhilCo How about instead of full templatization, add a helpName or helpLabel flag option that takes the place of everything to the left of the =, similar to how helpValue works for the right side of the =?