Adding all the docs changes to match command data and setup

[wolfo951]

These changes came from the auto-generated docs command. This will be the only way to generate command docs in the future.

[roopksaini]

Overall, this is looking good. The main thing I am seeing is re-ordering of options. From a usability perspective, we definitely want to be mindful of which options we present first for each command. Having iTwin and iModel IDs closer to the bottom (which seems to have happened for many commands) can have pros and cons. If people are using context / env variables, this can be helpful to directly engage with the specific options of a particular command. On the other hand, it feels natural to present the most fundamental ids closer to the top, since they indicate the entity we are working with.

In either case, we want to follow a consistent pattern.

[wolfo951]

Overall, this is looking good. The main thing I am seeing is re-ordering of options. From a usability perspective, we definitely want to be mindful of which options we present first for each command. Having iTwin and iModel IDs closer to the bottom (which seems to have happened for many commands) can have pros and cons. If people are using context / env variables, this can be helpful to directly engage with the specific options of a particular command. On the other hand, it feels natural to present the most fundamental ids closer to the top, since they indicate the entity we are working with.

In either case, we want to follow a consistent pattern.

@roopksaini The reordering currently is done alphabetically by the flag's name, with the exception of giving priority to the required flags. Having it in alphabetical order makes sense, as it provides an expectation when the user is searching for something in the possible options.

[roopksaini]

Overall, this is looking good. The main thing I am seeing is re-ordering of options. From a usability perspective, we definitely want to be mindful of which options we present first for each command. Having iTwin and iModel IDs closer to the bottom (which seems to have happened for many commands) can have pros and cons. If people are using context / env variables, this can be helpful to directly engage with the specific options of a particular command. On the other hand, it feels natural to present the most fundamental ids closer to the top, since they indicate the entity we are working with.
In either case, we want to follow a consistent pattern.

@roopksaini The reordering currently is done alphabetically by the flag's name, with the exception of giving priority to the required flags. Having it in alphabetical order makes sense, as it provides an expectation when the user is searching for something in the possible options.

Overall, this is looking good. The main thing I am seeing is re-ordering of options. From a usability perspective, we definitely want to be mindful of which options we present first for each command. Having iTwin and iModel IDs closer to the bottom (which seems to have happened for many commands) can have pros and cons. If people are using context / env variables, this can be helpful to directly engage with the specific options of a particular command. On the other hand, it feels natural to present the most fundamental ids closer to the top, since they indicate the entity we are working with.
In either case, we want to follow a consistent pattern.

@roopksaini The reordering currently is done alphabetically by the flag's name, with the exception of giving priority to the required flags. Having it in alphabetical order makes sense, as it provides an expectation when the user is searching for something in the possible options.

Ok that makes sense.