Is there a way / are there plans to provide lifecycle / hooks methods?

[refs]

Currently I'm providing structured config files alongside urfavecli, the problem with this is that config files for urfave are "just another way to declare flag values"; they are flat, not hyerarchical.

The workaround we're doing is ugly, as it goes against the defined priorities on urfavecli, since the only time I can set values on the flags are after these are already parsed (even the Before hook, flags have already been parsed by the time we reach it)

I've tried implementing the flag parsing myself but the prospects of maintaining this piece aside my usual work load is dark, and I haven't dig deep enough into urfavecli codebase to submit a patch, however I am willing to invest the time.

I guess I'm asking this because I've seen in some issues and comments that there is an active development for a v3, and perhaps this has been accounted for, perhaps not, or perhaps there is still room for feature submissions.

The reference point would be kong hooks, I have not personally used Kong, but these hooks seem to do just what we want.

This is the use case I'm trying to address: https://github.com/refs/urfave-yaml

[stale[bot]]

This issue or PR has been automatically marked as stale because it has not had recent activity. Please add a comment bumping this if you're still interested in it's resolution! Thanks for your help, please let us know if you need anything else.

[stale[bot]]

Closing this as it has become stale.

[dearchap]

@refs Yes we could implement this in v3. Are you willing to submit a PR ?

[dearchap]

@refs Could you provide a description of the hooks you are looking for ?

[dearchap]

Suggestion by user @axelrindle

The concept of lifecycle hooks sounds great to me. I'd like to propose the following:

• beforeFlags (runs before flags are parsed)
• afterFlags (runs after flags are parsed, but before commands are run)
• beforeCommand (runs before command actions are run; maybe merge with the previous?)
• afterCommand (runs after a command action has been run)

[dearchap]

@axelrindle we already have Before and After Actions for Command. I definitely see the value in Before & After Flags. The After Flags becomes tricky. When should it be called ? If there is an error in flag parsing(maybe invalid flag parsing etc) should the after flag action be called. What about if there are no parse errors but one of the following happens

1. help requested(via -h)
2. Required flags not set.

[axelrindle]

When should it be called ?

After all flags have been successfully parsed, but before the command action is executed.

If there is an error in flag parsing(maybe invalid flag parsing etc) should the after flag action be called.

I would handle this the same way the AfterCommand hook is handled to stay consistent.

help requested(via -h)

The occurence of -h should not stop flag parsing and thus not prevent the hook from running.

1. Handle flags
2. Notice -h
3. Call AfterFlags
4. Show help
5. Exit

Required flags not set.

Treat this as a parsing error and therefore only run hook on success.

[axelrindle]

I just thought about -h again and maybe it's better to don't call any hooks when help is requested as the help output should not change based on other flags.