Tags: alecthomas/kong
Tags
feat: add old "passthrough" behaviour back in as an option `passthrough:""` or `passthrough:"all"` (the default) will pass through all further arguments including unrecognised flags. `passthrough:"partial"` will validate flags up until the `--` or the first positional argument, then pass through all subsequent flags and arguments.
feat: support recursive injection of provider parameters
This allows provider functions to accept parameters that are injected by other
bindings or binding providers, eg. call the provider function with the root CLI
struct (which is automatically bound by Kong):
kong.BindToProvider(func(cli *CLI) (*Injected, error) { ... })
fix!: Include `--` in passthrough args (#436) Given a grammar like this: ```golang var cli struct { Args []string `arg:"" optional:"" passthrough:""` } ``` If Kong parses `cli foo -- bar`, it will populate `Args` with `[]string{"foo", "--", "bar"}` (including "`--`"). However, if Kong parses `cli -- foo bar`, will populate `Args` with `[]string{"foo", "bar"}` (leaving off `"--"`). This differs from the behavior of a passthrough Command, where `"--"` is included with the args in both cases. There are 3 places where `c.endParsing()` is called 1. When `node.Passthrough` is true: https://github.com/alecthomas/kong/blob/5f9c5cc822bdb888a3671c44d4688a6f602ecb90/context.go#L366-L368 2. When `arg.Passthrough` is true: https://github.com/alecthomas/kong/blob/5f9c5cc822bdb888a3671c44d4688a6f602ecb90/context.go#L451-L453 3. When `"--"` is encountered: https://github.com/alecthomas/kong/blob/5f9c5cc822bdb888a3671c44d4688a6f602ecb90/context.go#L384-L387 The first two do not also pop any tokens. The third one does. This commit makes `c.scan.Pop()` conditional, skipping it when the next positional argument is passthrough. I believe this will cause Kong to behave a little more consistently — and from my perspective, `--` is relevant for args intended to be passed through! — but it will change the behavior of existing projects that use `arg:"" passthrough:""`.
Make negatable flag name customisable (#439) * fix: Check if negatable duplicates another flag Add a check for flags with the `negatable` option if the negative flag conflicts with another tag, such as: Flag bool `negatable:""` NoFlag bool The flag `--no-flag` is ambiguous in this scenario. * feat: Make negatable flag name customisable Allow a value on the `negatable` tag to specify a flag name to use for negation instead of using `--no-<flag-name>` as the flag. e.g. Approve bool `default:"true",negatable:"deny"` This example will allow `--deny` to set the `Approve` field to false.