A follow-up for #116 (comment).
We are using yeoman generators in a way that was supported in pre-v0.17 days, but that is different from the new direction where yeoman is heading nowadays.
Our design is based on assumption that generators work like javascript methods: if we want to compose "loopback:model" with "loopback:property", we can simply generator#invoke() the later and the execution of the former would be postponed until the nested generator finishes.
However, that's no longer the case. These days, Yeoman uses a run queue with named groups (see "The Run Loop" in docs). When two generators are composed, their steps/actions are interleaved together via these named groups (e.g. "prompting", "configuring", "writing", "install", etc.). This composition does not allow repeated invocation of a nested generator, as we are doing now.
I think we should rework generator-loopback, refactor most of the prompts & actions so that they don't depend on yeoman features and the yeoman integration becomes just a thin wrapper. As a side effect, it should become easier to write unit-tests for prompts to verify input validation for example.
Mockup for illustration:
// model generator
generators.Base.extend({
prompting: {
promptForModelData: function() {
this.modelData = prompts.modelData();
},
promptForProperties: function() {
this.properties = [];
for (;;) {
var prop = prompts.propertyData(this.modelData.name);
if (!prop.name) break;
this.properties.push(prop);
}
},
writing: {
createModel: function() {
scaffold.model(this.modelData);
},
createProperties: function() {
this.properties.forEach(function(prop) {
scaffold.property(prop);
});
}
}
});
A follow-up for #116 (comment).
We are using yeoman generators in a way that was supported in pre-v0.17 days, but that is different from the new direction where yeoman is heading nowadays.
Our design is based on assumption that generators work like javascript methods: if we want to compose "loopback:model" with "loopback:property", we can simply
generator#invoke()the later and the execution of the former would be postponed until the nested generator finishes.However, that's no longer the case. These days, Yeoman uses a run queue with named groups (see "The Run Loop" in docs). When two generators are composed, their steps/actions are interleaved together via these named groups (e.g. "prompting", "configuring", "writing", "install", etc.). This composition does not allow repeated invocation of a nested generator, as we are doing now.
I think we should rework generator-loopback, refactor most of the prompts & actions so that they don't depend on yeoman features and the yeoman integration becomes just a thin wrapper. As a side effect, it should become easier to write unit-tests for prompts to verify input validation for example.
Mockup for illustration: