Skip to content

Conversation

@JoeColeman95
Copy link
Contributor

Moved the main CLI entry point from cmd/bk/main.go to ./main.go and switched to Kong for command parsing.

What's changed?

  • CLI entry point is now at the repository root
  • Using Kong parser with delegation to existing Cobra commands
  • All existing functionality works exactly the same
  • Moved generate.go to cmd/generate/ to avoid conflicts

Migration path

Later we can implement native Kong commands in separate files and remove the delegation layer. But for now this gets us the Kong foundation without changing any behavior. I've added comments to the sections we can rip out once we're ready to move on. I've created this with the assumption that we will continue to create the subcommands within their respective files.

Tested that all commands and help work the same as before.

Moved the main CLI entry point from `cmd/bk/main.go` to `./main.go` and switched to Kong for command parsing.

## What's changed?
- CLI entry point is now at the repository root
- Using Kong parser with delegation to existing Cobra commands
- All existing functionality works exactly the same
- Moved `generate.go` to `cmd/generate/` to avoid conflicts

## Migration path
Later we can implement native Kong commands in separate files and remove the delegation layer. But for now this gets us the Kong foundation without changing any behavior. I've added comments to the sections we can rip out once we're ready to move on. I've created this with the assumption that we will continue to create the subcommands within their respective files.

Tested that all commands and help work the same as before.
@JoeColeman95 JoeColeman95 requested a review from a team as a code owner September 25, 2025 16:42
Copy link
Contributor

@mcncl mcncl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks awesome, @JoeColeman95. I wonder should we use kong.UsageOnError() so that the help is outputted when only bk or go run . is used? Thoughts?

Copy link
Contributor

@scadu scadu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the hybrid approach, so we can keep existing functionality intact!
Left a few comments around error handling and help page.

@JoeColeman95
Copy link
Contributor Author

This looks awesome, @JoeColeman95. I wonder should we use kong.UsageOnError() so that the help is outputted when only bk or go run . is used? Thoughts?

Hey @mcncl, yeah I agree – the functionality isn't quite as expected there though 🙁, see this issue: alecthomas/kong#33

I've implemented the workaround stated there so we still get the expected behavior, I've delegated both bk and bk --help to Kong now and then anything bk x [y z] --help would result in Cobra help still.

Essentially, I've implemented exactly what you've suggested but added a condition to run() to catch and apply --help when there's no args passed on the base level

Adding `kong.UsageOnError()` and also catching any runs of the cli without any options to ensure help is displayed as shown as a workaround in this issue: alecthomas/kong#33
@JoeColeman95 JoeColeman95 requested review from mcncl and scadu September 26, 2025 09:59
@JoeColeman95 JoeColeman95 merged commit b9fd318 into main Sep 26, 2025
1 check passed
@JoeColeman95 JoeColeman95 deleted the SUP-4602/Kong-main.go branch September 26, 2025 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants