-
Notifications
You must be signed in to change notification settings - Fork 63
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
[WIP] Feature/blueprint clone command #133
base: master
Are you sure you want to change the base?
[WIP] Feature/blueprint clone command #133
Conversation
Hey @anithri! I have'nt added the specs because I first want to know if this looks good to you: The Process I followed to add a new command:I followed the same structure
Each commit has a more comprehensive explanation of what each added class does. QuestionsIs there a correct way to get the |
Why is this change necessary? For the clone command there needs to be a model to clone files. How does this address the issue? BlueprintCloner is initialized with a blueprint and some options. Then it implements a `clone()` method that will clone all the blueprint files. It ignores blacklisted files (.ds_store, .git, .gitkeep))
Sub-command Clone simplements a `run(blueprintName, args)` that simply calls the task `CloneBlueprint` to clone a blueprint.
CloneBlueprint is initialized with the blueprint that needs to be cloned and some options for the destination blueprint. CloneBlueprint calls BlueprintCloner to clone the files
Implements a slightly different version of build-blueprint-commands and build-blueprint-command. If the cli will have more commands it might be a good idea to make those two files adaptable to different descriptions, usages, etc.
fb32cd3
to
e8ef3d1
Compare
Codecov Report
@@ Coverage Diff @@
## master #133 +/- ##
=========================================
- Coverage 82.17% 74.8% -7.37%
=========================================
Files 27 28 +1
Lines 387 389 +2
=========================================
- Hits 318 291 -27
- Misses 69 98 +29
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good so far. Most of the really big issues are due to upstream api's not being finalized yet.
src/models/blueprint-cloner.js
Outdated
const FILES_BLACKLIST = ['.ds_store', '.git', '.gitkeep']; | ||
|
||
export default class BlueprintCloner { | ||
constructor(blueprint, options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's use constructor(blueprint, options = {})
instead of line 12
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
src/cli/cmds/clone.js
Outdated
|
||
module.exports = { | ||
command: 'clone <blueprint> <name>', | ||
aliases: ['g', 'gen'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably the wrong aliases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed... aliases are optional so you can set an empty array or remove the key entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I've fixed it.
.usage(usage) | ||
.option('dry-run', { | ||
alias: 'd', | ||
describe: "List files but don't generate them", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 different quoting styles used in this line and last/next. If you install and run prettier, that will help with your formatting.
This is the only descepency that eslint finds is in switch statements. Prettier wants cases indented, and eslint wants them flush with the switch statement.
// NO
export default function(state = defaultState, action) {
switch (action.type) {
default:
return state;
}
}
// YES
export default function(state = defaultState, action) {
switch (action.type) {
default:
return state;
}
}
And so I've been editing it back after i yarn run pretty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prettier would use the two different quoting styles, because the describe string has an embedded single quote. Eslint should already allow that (and complain if double quotes are used in any other circumstance). The rule for quoting was modified by a recent PR
"quotes": [2, "single", {"avoidEscape": true}],
I prefer the prettier formatting for switch, and not having any manual step to undo it! This can also be accommodated by eslint:
"indent": [2, 2, {"SwitchCase": 1}],
Suggest we make that change in .eslintrc
|
||
import { fileExists } from '../util/fs'; | ||
|
||
const FILES_BLACKLIST = ['.ds_store', '.git', '.gitkeep']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely need a FILES_BLACKLIST
. I'm just wondering if there's value to making it an rc option that would include what you have here as defaults.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth it 🤔
If we set the defaults it's always good to let the user add more customization.
But in what other circumstances will we need to blacklist files besides clone
?
src/models/blueprint-cloner.js
Outdated
} | ||
|
||
clone() { | ||
const blueprint = this.blueprint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the time a blueprint is added to the collection, it will already have a validated existent path to itself. And will also have a method that returns it's files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
I'll make the changes once the new api is ready.
src/models/blueprint-cloner.js
Outdated
const blueprint = this.blueprint; | ||
this.ui.writeInfo('cloning blueprint...'); | ||
|
||
const cloneToDirectory = this.cloneToDirectory(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The directory we clone to will be determined at the settings level, something like rc.get('path.bpTarget
). So by this point in execution, you'll either have a falsy value or a validated, existing path you can write to. Falsy values should generate a warning or an error.
It seems to me that making assumptions based on the search path order, is risking unintended consequences. Better to get 'permission' with an explicity defined path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree, it is risky to make assumptions based on the search path order and it does make sense to get that permission
from the explicit path.
I was aware that I will need to change the cloneDirectory
to something like rc.get('path.bpTarget')
.
I will make the change once the new rc
api is ready.
src/models/blueprint-cloner.js
Outdated
return path.resolve(settings.blueprints.searchPaths[0], this.newBlueprintName()); | ||
} | ||
|
||
newBlueprintName() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is another thing that should be from rc
, so that we can add --name <newName>
or --cloneTo
or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great idea.
Let me check if I am understanding correct, rc will have:
- All the settings from the
.blueprintrc
. - The UI environment to write.
- The arguments sent from the CLI.
import Task from '../models/task'; | ||
import BlueprintCloner from '../models/blueprint-cloner'; | ||
|
||
export default class extends Task { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets add an explicit class name, if only to make our IDE's happier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI... none of the other Tasks currently specify a class name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, that's true. AirBNB recommend the existing way too:
https://github.com/airbnb/javascript#modules--prefer-default-export
TIL
_cloneDeep(bp[blueprint.name]) | ||
)); | ||
|
||
const buildBlueprintCommands = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the blueprints will already be found, read, and have it's settings already merged. Again the api is not quite ready yet, but soon. And any suggestions would be most welcome. see #132 for current thinking
src/cli/cmds/clone.js
Outdated
command: 'clone <blueprint> <name>', | ||
aliases: ['g', 'gen'], | ||
describe: 'Clone a blueprint with a different name', | ||
builder: yargs => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a closer look at this before providing final feedback... this seems to fall between the pattern used for simple yargs commands like init and the more involved pattern used to support the blueprint specific generate commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The clone logic looks good. The CLI needs handlers similar to:
// src/cli/cmds/generate
...
getHandler().onRun('generate', handlers.handleRun);
getHandler().onHelp('generate', handlers.handleHelp);
...
These are used by generate so it can parse argv in 2 stages, the first pass gets enough information to setup the environment and load the available blueprints, the second pass then runs the specific blueprint generate command, or outputs help.
Note that for the handlers to work generate.js
module.exports
does not include a handler
property/function. And the builder
property/function configures yargs
with .exitProcess(false)
and .fail(fn)
.
It's not clear that the clone command needs access to the blueprint specific options (yet?) so it could be a single command handler rather than needing to buildBlueprintCommands. I'm open to discussion on that.
I think the basic CLI interface would be:
bp clone <blueprint> [new_name]
Which would copy from wherever it is found on the search path to the local directory, optionally setting a new name. This would also support cloning a blueprint that is already in the local directory to a new name.
The other thing to consider is the help output:
bp help clone
src/cli/cmds/clone.js
Outdated
command: 'clone <blueprint> <name>', | ||
aliases: ['g', 'gen'], | ||
describe: 'Clone a blueprint with a different name', | ||
builder: yargs => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a closer look at this before providing final feedback... this seems to fall between the pattern used for simple yargs commands like init and the more involved pattern used to support the blueprint specific generate commands.
Hey @anithri: I see 3 important changes:
1 change that we need to discuss if it's worth changing:
|
Hey @jamesr73 I think you are right, So I will make the change to not build all blueprint commands but only build the clone command I am not sure yet how the generate I'll refactor the clone command with the handlers. |
Hey @walreyes The handlers are just callbacks registered with EventEmitters that are triggered after |
Why is this change necessary? I used buildBlueprintCommands but `clone` does'nt really needs the blueprint options, with the name it's enough to clone the files How does this address the issue? Deletes clone/buildBlueprintCommands and uses handles to handle run
@jamesr73 got it. So I've refactored the What do you think? |
@walreyes looks good, much cleaner and clearer. I think we should also add a handler for help. Yargs will already provide it's default help for the command name, usage and options. The help handler should list the available blueprints. It doesn't need to use yargs to generate this, just log to the console (or use the ui). |
|
||
export default handlers; | ||
|
||
function handleRun(argv, yargs, rawArgs = process.argv.slice(3)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rawArgs
parameter can be removed as it isn't needed here in the same way as it was for generate
.
const blueprintName = argv.blueprint; | ||
const environment = getEnvironment(); | ||
|
||
if (blueprintExists(environment.settings.blueprints, blueprintName)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pedant suggestion...
if (blueprintInEnvironment(blueprintName, environment) {
...
}
What does this PR do?
blueprint clone <blueprint-name> <name> [options]
command.TODO
settings.cloneTo