-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements for extending & help template overwriting #1338
Conversation
I see issues about people wanting to disable the built-in help, but not issues about what people are replacing it with, or requests to make more support routines public to let people build their own. We might get more interest if #1296 lands and it is easier to override the help. The code uses arrays of strings internally to build up the help in an efficient and convenient way. I don't think that is a very natural form to return to the user for building custom help though. Some different ideas for what to expose could be:
The help code is a bit of a historical mess! I do like that you have tidied it up while making the changes. |
With my changes I can do something like this: |
Nice example of fancy help! Thanks. #1296 just provides hooks for before and after and overriding the built-in help, it does not provide any assistance doing the fancy help. |
May be instead of: function padDetails(value, description) {
if (description) {
return [pad(value, width), optionalWrap(description, descriptionWidth, width + separatorWidth)];
}
return [value];
}; you prefer: const utils = {
pad: val => pad(val, width),
wrap: val => optionalWrap(val, descriptionWidth, width + separatorWidth)
};
const renderDetails = params.renderDetails || ((value, description, utils) => {
const data = description ? [utils.pad(value), utils.wrap(description)] : [value];
return data.join(separatorStr).replace(/^/gm, valueIndentStr);
});
function prepareDetails(value, description) {
return renderDetails(value, description, utils);
}; |
I see running the code and dumping |
pushed the changes, now {
usage: 'string',
description: 'string',
args: ['string'],
options: ['string'],
commands: ['string']
} |
I am wondering about what approach to take. This is just an idea. There is already access to some of the content that is displayed in the help. There is There are a few pieces of logic that are buried in code. e.g. const help = this.options.map((option) => {
const fullDesc = option.description +
((!option.negate && option.defaultValue !== undefined) ? ' (default: ' + JSON.stringify(option.defaultValue) + ')' : '');
return padOptionDetails(option.flags, fullDesc);
}); I wonder how it would go separating the construction and the formatting, and making the constructed parts available directly? So the built-in formatting code would look like (say): const help = this.options.map((option) => {
return padOptionDetails(option.flags, option.fullDescription());
}); |
Thanks @cravler |
Experimenting in #1346 with refactoring and making help building blocks accessible. |
Closing this in favour of #1365 |
Example