Issues & suggestions

[WoLfulus]

First of all, thanks for the framework, it's (imho) the best I've found so far (api/interface).

There are some little things that I found to be either counter intuitive and/or confusing, or just hard to accomplish. I'd like to ask if it's by design or if we can improve it somehow.

---

Promise support

Problem

Would be nice if type() supports async handlers and actually await them on call, the same goes for option actions. At the moment they are carried to the rest of the framework as (both type and values) as Promises instead of the resolved (awaited) value.

Use case

I tried creating a "config" type that reads and parses the config file specified through a --load-config <path:config> option, but if I do that, I now have to await the value anywhere I need to use it.

---

Option's default values won't trigger action and the type handler itself

Problem

Actions in options are a great way to "react" to values being passed by the user and it works great, but imho "default values" would be the same as if the user passed them to the CLI. The framework won't call the option action for default values, which would be great if it did so we could at least react to them.

Use case

Similar to the previous issue, I tried using action instead of type to load my configs,--load-config <path> that is passed to the CLI and merge it into the current config object I have. If I don't explicitly pass

"Workaround"

If I completely remove default from the option itself and do parsing like: command.parse(['--my-opt', 'default1', '--my-opt', 'default2', ...Deno.args]) it will trigger for each one of the default values + user specified ones, but the problem with this is that if you are now stuck forever with default values too.

Side note

action imho implies something that will happen once everything is already parsed/ready, right now "action" in options are more like a transformer/validator/aggregator instead. I'd expect an action to be taken only once after all type handler, validations and transformations just like a command does.

---

Context & command pipeline

Problem

I haven't found a way easily pass down a context to sub commands or aggregate custom data to the command pipeline. It would be nice to access parent command data when running sub commands together with making sure all parent commands have a way to run logic before moving to a sub command.

Use case

For example if the CLI interacts with an API, the parent command could load the API token from a config file, create the SDK instance and make it available to the context so that subcommands can use it. I imagine this as a "scope action" that runs (in order) when the command is part of the command chain.

I saw that there's a globalActions (I haven't tested if it would work the way I expect), but just from the naming itself I imagine it would cause confusion since with that name I expect it to run all the time regardless of the command being executed, as for a scopeAction it would trigger only when that specific command is part of the command chain/context/scope.

For example: if I add scopeAction to cmd_b, I expect it to trigger for my-cli cmd_a cmd_b cmd_c, but not for my-cli cmd_a or my-cli cmda cmdd

---

Also, if anything I said makes sense and is accepted, let me know if it would be better to implement it myself and I'll submit a PR.

Thanks

[c4spar]

Thx for your feedback @WoLfulus and sorry for the late reply!

Promise support

I'm aware of this limitation. The plan is to add support for async types in the future.

Option's default values won't trigger action and the type handler itself

The type handler and also the action handler will not be called for default values, as the default value is currently the already parsed value.
I was thinking about changing it so that the default value is handled as a raw value, since the default value is also shown in the help output. It could make sense to change it, but it would be a breaking change.

Context & command pipeline

A context is already partially implemented and is planned to be expose in cliffy 2.0.