blueprint options

[jamesr73]

Since revisiting PR #79 a few days ago I've been thinking some more about the CLI and how I may be able to help move it towards the 2.0 release.

There are several issues that relate to options specific to one/some blueprints: #5, #25, #72, #88 and #101. There are also a couple relating to how commands are parsed: #10 and #96.

Whilst passing additional options to blueprints is supported at the moment they are hidden from the user unless they review the blueprint source. I've been thinking about a more formal mechanism for blueprints to define the options that they support such that the help command could document them. Making it clearer what could be passed on the command line and/or added to (the extended) .reduxrc. E.g.

> bp help generate duck

Options:
--namespace      the namespace (app/module name) to use in action type constants
--reducer        the reducer name, also used in action type constants
--types          comma separated list of types
--actions        comma separated list of actions
--path           relative path for __duck__ token, default redux/modules

I've done a little investigation and I think this can be achieved quite easily by switching out commander for yargs and then building sub-sub-commands from the available blueprints automatically, allowing them to specify options (in yargs format) if necessary. Existing blueprints and/or those that don't need to define options would continue to work as they are with the CLI creating default commands for them (using the existing description()). The blueprint would not need to define the action that yargs performs, this would be setup to run the blueprint automatically by the CLI.

Using yargs also makes it trivial to take care of #10 and #96.

If this sounds useful I'm happy to work on a PR.

[anithri]

I think this sounds useful, it solves several problems at the same time, expands capabilities pretty easibly.

There are some things to consider.

• Just switching to yargs is a win for discoverable commands. Could also allow us to have user defined shortcuts
• the rc library that's going to be used for blueprint-rc allows env variables to define specific values blueprint_foo__bar__baz => foo.bar.baz. Can we take lessons from that pattern? Should we emphasize the --foo_bar style over the ENV? Are there distinct uses for each?
• There is going to be some sort of sub-blueprint (partials). I think they should be co-located with the other blueprints. That means (for generate especially) that we need to have a way to distinguish between generate-able blueprints and import-able partials.
• A major goal of 2.0 is sharable blueprints, almost certainly through NPM. So we'll need to be sure to be able to read blueprints from them.
• Shareable also means from multiple directories. blueprintrc will define search path for blueprint directories as well as there being an assumption of checking each directory that had a blueprintrc will be checked to see if there is also a blueprints dir there.
• We need to be able to define default and generator specific data in the .blueprintrc files. At some point the command arguments will have to be merged with that data.
• 2.0 will be adding at least two commands. config command for cli #107, copy or clone command for cli #108 how will this effect them?

[anithri]

Looking over the other issues, I think that this would also address #24, #25, and #72

[jamesr73]

Thanks for the feedback @anithri.

• Just switching to yargs is a win for discoverable commands. Could also allow us to have user defined shortcuts

Agreed. Plan is to use yargs commandDir to specify the main commands, so easy to add to without having to modify the main/root entry point. Also only needs a single entry point in bin. Supports multiple aliases for commands, e.g. generate | gen | g. Similarly, can alias the names of blueprints, e.g. redux-connected | container | smart.

• the rc library that's going to be used for blueprint-rc allows env variables to define specific values blueprint_foo__bar__baz => foo.bar.baz. Can we take lessons from that pattern? Should we emphasize the --foo_bar style over the ENV? Are there distinct uses for each?

yargs also supports env vars. I haven't looked at rc but we could use either/both.

• There is going to be some sort of sub-blueprint (partials). I think they should be co-located with the other blueprints. That means (for generate especially) that we need to have a way to distinguish between generate-able blueprints and import-able partials.
• A major goal of 2.0 is sharable blueprints, almost certainly through NPM. So we'll need to be sure to be able to read blueprints from them.
• Shareable also means from multiple directories. blueprintrc will define search path for blueprint directories as well as there being an assumption of checking each directory that had a blueprintrc will be checked to see if there is also a blueprints dir there.

Using Blueprint.list() (or a derivative) when building out the command line means we only need to solve these in one place.

• We need to be able to define default and generator specific data in the .blueprintrc files. At some point the command arguments will have to be merged with that data.

yargs helps us here too with the config option. Perhaps even the extend variation.

I'm also wondering if we could store the values configured in blueprintrc directly in the Blueprint when it's loaded so they can be made available to the CLI builder when defining the options. I.e. the CLI help for a blueprint could show the default/configured values for options.

• 2.0 will be adding at least two commands. config command for cli #107, copy or clone command for cli #108 how will this effect them?

#107 List and #108 Copy commands will be easy to add to this setup.

I'm thinking about adding the list command along with this change by reusing the help output currently tied to redux help generate. And making the list command the default so that if you simply run blueprint or bp you see the list of available blueprints.

[jamesr73]

I'll put together an initial PR for further discussion.

[anithri]

Thanks for the great work @jamesr73
Closing