A new command line tool and developer framework for scaffolding out GitHub projects. Generate offers the robustness and configurability of Yeoman, the expressiveness and simplicity of Slush, and more powerful flow control and composability than either.
even though
answers passed in the callback is defined { '¯_(ツ)_/¯': { why: 'dunno' } }
@dtothefp
base-questions stores the answers on app.cache.answers after the question is asked. I copied your example and it works for me. I changed the imports to var foo = require(‘…’) and changed export default to module.exports = since I’m not sure how you’re doing the transpiling step.
Which version of
generate are you using?
It could be that an older version has an older
base-questions or that something is happening during the transpiling… also, you should be passing a callback to the default task and calling it after the console.log to indicate that the task has finished.
not sure the best way to test generator functionality locally?
I have a directory structure like this
./packages
├── generator-slo-mo
│ ├── dist
│ │ └── index.html
│ ├── generator.js
│ ├── package.json
│ └── src
│ ├── generator.js
│ └── index.html
└── slo-mo
├── bin
│ └── cli.js
├── dist
│ ├── github.js
│ ├── slack.js
│ ├── slo-mo.js
│ ├── speedcurve.js
│ └── task.js
├── package.json
├── src
│ ├── github.js
│ ├── slack.js
│ ├── slo-mo.js
│ ├── speedcurve.js
│ └── task.js
└── test
└── sample-spec.js
where generator-slo-mo/generator.js is my compiled generator from src/generator.js
and I run
generate in an npm script in package.json
it all works, I'm just not seeing those
answers appended on the cache
@jonschlinkert I'm not sure the difference between "cached answers" and "persisted answers"
I was under the impression that
answers would be added to app.cache.answers after the ask
@doowb I'm on
"version": "0.9.8"
I can make a small example and push it up to github
I thought it might be a version issue
by cached I meant "in-memory" and by persisted I meant stored on disk and available across sessions
just out of curiosity why if you have a default task does it look like
[14:13:48] ✔ running tasks: [ 'default:default' ]
with the doubled up
default?
so in that case it's coincidental that you're running the
default task on the default generator (which is the local generator.js if you happen to have one)
but you can also namespace generators locally by making them sub-generators. Example
module.exports = function(app) {
this.task('default', function(cb) {
console.log(app.namespace, 'task >', this.name);
cb();
});
// sub-generator "foo"
this.generator('foo', function(foo) {
this.task('default', function(cb) {
console.log(foo.namespace, 'task >', this.name);
// run the `default` task on `app`
app.build('default', cb);
});
// sub-generator "foo.bar"
this.generator('bar', function(bar) {
this.task('default', function(cb) {
console.log(bar.namespace, 'task >', this.name);
// run the `default` task on `foo`
foo.build('default', cb);
});
});
});
};
the awesome thing about sub-generators is that you can require in other generators, like how you organize your tasks sometimes into different files