-
-
Notifications
You must be signed in to change notification settings - Fork 298
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
#inDir() should also accept a source
path to preload a testing dir with contents
#573
Comments
Im running into this problem as well but I think the second param should be a boolean which should mean: if true, don't delete the contents of the temp directory otherwise do. |
Or maybe just giving control via a callback once the dir is cleaned? In this callback you manually copy or generates files or whatever really. |
callback is better. |
I'd prefer both callback and a function to automate it, and giving it a second thought, maybe the following is better? helpers.run('../../generator-foo/app')
.inDir(path.join(__dirname, 'temp'))
.withContents(path.join(__dirname, 'fixtures', 'some-content-to-update'))
.withContents(path.join(__dirname, 'fixtures', 'some-other-content'), path.join(__dirname, 'fixtures', 'some-more-content'))
... |
I think the callback syntax is enough:
You could just a npm module to move files and call it in the callback |
@eddiemonge ++ I like that syntax and it is way more flexible than having too many predefined behavior. We'd just need to handle async action too. |
@eddiemonge cool, this is indeed clean and flexible, and I can take care of it after I clean up #570. On a side thought, do we want to handle the case when the callback is doing something async? Without async, the change could be as simple as: RunContext.prototype.inDir = function (dirPath, cb) {
var release = this._holdExec();
helpers.testDirectory(dirPath, _.compose(cb || _.noop, release));
return this;
}; As you see, calling Thoughts? @SBoudrias |
… a chance to alter the environment to the a specific way and expect `env` and `generator` reflects such settings. - Emits `ready` event right before calling `generator.run()` to allow any last minute operation on the `generator` - Deprecating `onEnd`, instead emits 'end' event as `generator.on('end')` - Implement `withGenerator()` to mock generator dependencies - accepts optional second parameter in `inDir` as a callback function. fixes yeoman#564, yeoman#565, yeoman#573
… a chance to alter the environment to the a specific way and expect `env` and `generator` reflects such settings. - Emits `ready` event right before calling `generator.run()` to allow any last minute operation on the `generator` - Deprecating `onEnd`, instead emits 'end' event as `generator.on('end')` - Implement `withGenerator()` to mock generator dependencies - accepts optional second parameter in `inDir` as a callback function. fixes yeoman#564, yeoman#565, yeoman#573
… a chance to alter the environment to the a specific way and expect `env` and `generator` reflects such settings. - Emits `ready` event right before calling `generator.run()` to allow any last minute operation on the `generator` - Deprecating `onEnd`, instead emits 'end' event as `generator.on('end')` - Implement `withGenerator()` to mock generator dependencies - accepts optional second parameter in `inDir` as a callback function. fixes yeoman#564, yeoman#565, yeoman#573
Done! |
This will help testing scenarios of running a generator in a folder with existing project contents.
The text was updated successfully, but these errors were encountered: