MarcDiethelm
Enable creating different templates and maybe skins directly when adding a module with yeoman
Also you can't choose to create every standard file anyway once you chose to change the default setup (step two after yo xtc:module).
We could ask the user if he wants to create skins immediately (and start the skin generator) but it means an additional question. A question which in the standard case is probably one too many. What do you think?
Agreed the selection should offer the option to create all the default files anyway.
As for template creation I don't think I see the need for that. A template is just a .hbs file with a little placeholder (wireframe styles) inside... Are you saying you value that placeholder so much you want a generator for it? :)
I guess there could be a question like "Do you want to create any templates and/or skins?" with a default selection of "no", if you answer yes you get into a new routine. You could perhaps just write a comma separated list of templates and then skins you want to add. And yes I'd like a template generator which adds the default wireframe box and label with a sensible naming, so I don't have to create the file and write or copy this markup.
I guess there could be a question like "Do you want to create any templates and/or skins?"
I wonder how this would fit with the existing flow. Let's draft an improved flow and try to integrate the things you are proposing. See https://github.com/SBoudrias/Inquirer.js for the possible menus we can use in the CLI...
[?] What's the name of the new module: foo
After that the user gets a list prompt:
Default module contents: A template, style sheet, JS module with tests, readme.md
Generate default module contents?
> Defaults
Customize
If the default is chosen the files are generated and the generator ends. If the user chooses to customize, she gets a checkbox menu (instead of the list menu).
⬢ JS
⬢ CSS
⬢ Template
⬢ Tests
⬢ Readme
⬡ JS skin
⬡ CSS skin
The top menu items would be pre-selected. Now we could follow up with questions about templates and skins (as selected):
Please enter a list of templates to create: foo
User enters his choices:
Please enter a list of templates to create: foo bar baz
Input can be separated with spaces or commas.
We would do the same for skins.
The user then get's a list of files that will be created and is asked to confirm his choice. If he confirms we generate the files, else we jump back to the checkbox menu again.
This flow would make it possible to create templates and skins from the start. We could create an additional generator to allow creation of any of the checkbox choices into an existing module (similar to the existing skin generator). This generator would also support creation of multiple skins/templates at once.
What do you think?
This looks like a really good way of handling template and skin generation to me. I guess you could leave the confirmation request though, just add a short hint beforehand which informs you of how the list of templates/skins should be formatted. If you do something wrong you can easily just delete the file(s) after (and we're not microsoft :P).
Ok. Being able to fix a mistake after extensive customization is a good idea methinks. I'll keep it.
Another thing with module and skin generation is the imo missing possibility to just skip all those questions and let yeoman simply generate the defaults (because that's what I do most of the time).
So for xtc:module couldn't there be a flag like -d (for default) so it directly generates the standard files? So for example: yo xtc:module example -d.
For skin generation it would save some time (searching the module) if you could just pass the module and skin name, like so: yo xtc:skin example alternate.
In your code you could easily test for the amount of arguments and handle them differently I suppose?
:+1: That's an awesome idea. yo provides the following three parameters to generators: args, options, config. So there potential to completely pre-configure the generator when calling it from the CLI.
So to complete your initial suggestion let's have this:
-d, --default | Silently create a default module. Only asks for name if needed.
Also you can't choose to create every standard file anyway once you chose to change the default setup.
Partial fix: You now have that option in 0.8.0-beta4