feat: expose ValueFormatter option through HelpOptions for custom HelpPrinters

[mpeyper]

Motivation

When implementing custom HelpPrinter functions, there was no way to access the configured HelpValueFormatter (set via kong.ValueFormatter()). This meant custom help printers couldn't format flag and argument values consistently with the rest of Kong's help system.

The ValueFormatter is used to customise how help text is displayed for flags and positional arguments (e.g., adding environment variable suffixes, custom formatting, etc.). While this was available to Kong's built-in help printer, custom help printers had no access to it.

Changes

This PR exposes the HelpValueFormatter through the HelpOptions struct that is passed to custom HelpPrinter functions, enabling custom help implementations to format values consistently with the application's configuration.

Key changes:

• Added ValueFormatter HelpValueFormatter field to HelpOptions struct
• Refactored Context.PrintUsage() to use a new internal Context.printHelp() method that ensures ValueFormatter is always set in HelpOptions before calling the help printer
  • Updated all help invocation points to use the new pattern
• Refactored usages of helpWriter.helpFormatter to use helpWriter.HelpOptions.ValueFormatter instead and removed the old field

Implementation Details

The refactoring ensures that whenever a help printer is called (whether through --help, ctx.PrintUsage(), or error handling), the ValueFormatter is automatically populated from kong.helpFormatter into the HelpOptions.

Backward Compatibility

This change is fully backward compatible:

• Existing custom help printers continue to work without modification
• The new field is simply available if custom help printers want to use it
• No breaking changes to any public APIs

[mpeyper]

This could be collapsed into PrintUsages if we wanted to, but it would make the usage in kong.go look a bit strange:

_ = parseErr.Context.printUsages(parseErr.Context.helpOptions.Summary)

[alecthomas]

Seems reasonable, can you add a test?

[alecthomas]

Oh ah it just exposes what was already there, so probably not test worthy.

[mpeyper]

Oh ah it just exposes what was already there, so probably not test worthy.

Yeah, most the refactoring is of existing functionality (that's already tested, right? 😉)