Looks like a lot of the logic for this lives in https://github.com/urfave/cli/blob/main/help.go and the templates in here (unfortunately not exported!) are here: https://github.com/urfave/cli/blob/main/template.go

Use this as an exercise in minimising the diff, that's your challenge - how can you get to near zero red/green lines in the diff here for the documentation output, aiming to only make changes where the existing script is getting it wrong (mostly missing some things I believe).

@akaladarshi : I assume you'll re-request review when you're ready for it to be looked at again.

Very close @akaladarshi, good work so far. I haven't done an in-depth review of the actual code, I'm mainly looking at the output and assuming that the code is good, I'll look over that next.

@rvagg I think I found a minimum solution for this we can directly use the urface cli package for generating, Initially I though we need to print everything (hidden), but this will directly print the correct format value.

     customAppData := func() map[string]interface{} {
		return map[string]interface{}{
			"ExtraInfo": g.app.ExtraInfo,
		}
	}

	cli.HelpPrinterCustom(header, cli.AppHelpTemplate, g.app, customAppData())

@rvagg I think I found a minimum solution for this we can directly use the urface cli package for generating, Initially I though we need to print everything (hidden), but this will directly print the correct format value.

     customAppData := func() map[string]interface{} {
		return map[string]interface{}{
			"ExtraInfo": g.app.ExtraInfo,
		}
	}

	cli.HelpPrinterCustom(header, cli.AppHelpTemplate, g.app, customAppData())

Removed the above change in favour of app.Run(args[]string), because it was not printing the default values of flags. Anyway app.Run internally uses cli.HelpPrinter to print the commands.

Squashed down to a single commit and rebased onto current master in this branch.

After a make clean deps, the current master has make docsgen-cli running at 25s. This branch does the same in 17s. The catch is that docsgen-config is a separate target and still requires the lotus and lotus-miner binaries (just not lotus-worker), so make docsgen-cli docsgen-config, being now a two-step process that first requires a partial compile (for go run) and a full compile for the two binaries needed for config, so it ends up ebing 30s, i.e. longer. But at least you can choose, and the config files are just another batch of work to be done that I want to separate from this PR.

@rjan90 please have a look at the changes I made in the head commit here, I've put docsgen-config as a separate required target to be run on releases and I also put it in CI.

I think follow-up work here to make the config output should be straightforward but it would be worth testing whether it should be part of the same binary or not, it might be faster to keep it in the same thing rather than have two binaries it has to setup and execute.

OK, nevermind about the follow-up task, I just bundled it in here and got rid of the need to lotus config > out at all, so now it's all part of the docsgen-cli app so it runs relatively quickly in the same binary. It's still not super-fast because it does need to load and compile a lot of code in the various paths that the CLI app touches, it just doesn't need to form a proper binary with all of the inclusions that a full make does.

make docsgen-cli after a clean deps takes 17s now. So we've shaved off approximately 1/3rd of the time for this task. I've got rid of the docsgen-config task I introduced.

@rjan90 if you wouldn't mind reviewing that would be appreciated. You're welcome to focus on the two additional commits I added since they are minimal and I already reviewed the larger initial commit.