Skip to content
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

Naming convention to allow an option/argument to override a prompt #957

Closed
PatrickWalker opened this issue Sep 9, 2016 · 3 comments
Closed
Labels

Comments

@PatrickWalker
Copy link

Hey

Probably looking at this from the wrong angle so apologies if this is already covered.

I have a collection of sub-generators (one to create a polymer element and one to do some company readme stuff for example) and they both have some shared values and some other values not shared.
IE Element Name is used in both but lets say I have some additional information in the readme which isn't needed to generate the element "Author" or similar.

My parent/wrapper generator can prompt for name and then pass that in as an option or argument to the sub generators. That means the option needs to be checked and logic put in all the generators to over-ride the prompting essentially right?

I saw https://www.npmjs.com/package/yeoman-option-or-prompt which offers a way to do that.

Would there be any value in having a convention that was built in to yeoman that allowed an option/argument to take precedence over a prompt in a way that is built in?

So basically I would pass in an argument called prompt-name or similar to https://github.com/Polymer/polymer-cli/blob/master/src/init/element/element.ts and it would know not to prompt the user for the name in this case to avoid a situation when a user gets prompted for the same information by 2 different sub-generators?

I understand we have the ability to do all of this now it's more just looking for a convention to reduce the overheard on the generators to handle the options/arguments and have a prescribed way of doing this behaviour in an easier way

@PatrickWalker
Copy link
Author

Perhaps it would also be possible in a situation were a generator always wants to prompt (and doesn't care if it's been asked before) to continute to do that by having a flag or an type of input-always and in this situation they may just want to use the supplied value as a default or something?

@SBoudrias
Copy link
Member

Hey, you might be interested in the discussion we had about potential future API #894

@github-actions
Copy link
Contributor

github-actions bot commented Jan 1, 2020

This issue is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the stale label Jan 1, 2020
@github-actions github-actions bot closed this as completed Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants