This pr updates all cli subcommands that previously relied on root-level flags (streams, lint, test, echo) to now explicitly define those flags such that they appear in help-text and can be specified after the subcommand itself.
This means previous commands such as connect -r ./foo.yaml streams ./bar.yaml can now be more intuitively written as connect streams -r ./foo.yaml ./bar.yaml and so on. The old style will still work in order to preserve backwards compatibility, but the help-text for these root-level flags has been hidden.
I tried a few different ways of implementing this behaviour, where if a subcommand defines a flag foo that collides with a root level flag foo the user is able to specify either and it functions the same. Unfortunately I couldn't find a way of doing this with the urfave/cli package itself, so we've had to implement our own extraction of those flags at the root level context which is passed to all subcommands.
One day we'll refactor all of this to remove the root level flags and although there will be some work there to simplify things for the most part we'll be replacing things like opts.RootFlags.GetResources(c) with c.StringSlice("resources"), so it won't be a huge effort.
This pr updates all cli subcommands that previously relied on root-level flags (
streams
,lint
,test
,echo
) to now explicitly define those flags such that they appear in help-text and can be specified after the subcommand itself.This means previous commands such as
connect -r ./foo.yaml streams ./bar.yaml
can now be more intuitively written asconnect streams -r ./foo.yaml ./bar.yaml
and so on. The old style will still work in order to preserve backwards compatibility, but the help-text for these root-level flags has been hidden.I tried a few different ways of implementing this behaviour, where if a subcommand defines a flag
foo
that collides with a root level flagfoo
the user is able to specify either and it functions the same. Unfortunately I couldn't find a way of doing this with the urfave/cli package itself, so we've had to implement our own extraction of those flags at the root level context which is passed to all subcommands.One day we'll refactor all of this to remove the root level flags and although there will be some work there to simplify things for the most part we'll be replacing things like
opts.RootFlags.GetResources(c)
withc.StringSlice("resources")
, so it won't be a huge effort.