-
-
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
Set a local destinationPath to a composed sub-generator with #composeWith()
#872
Comments
Yes, this would be very useful. Although there's some historic reasons as to why destination root is globally shared. Basically, we have a lot of generators who're not relying on the built-in files utilities. We got a lot of people using some raw This have been working well to get older generators to update to new versions of the generator framework more easily, and to allow some amount of composition with legacy generators. Binding the destination roots to the CWD, just makes bad generators harder to break. That being said, we should totally reconsider this for 1.0. It'd be way easier if you could just tell a generator to run inside of x folder. For now though, you could ask the author of |
@SBoudrias Thanks for your answer it's much more clear now. I dont have enough knowledges regarding the yeoman-generator code structure to provide a PR for now so I will follow your recommendation to request a PR to the sub-generators I am using with a path option. |
@canercandan can you give me some insight why do you need this feature? |
Sure, let says you are using the travis generator twice on two sub-directories of the generated project, that means the resulting files hierarchy may look like:
The easiest way to accomplish this is by adding a |
okay, is there any real life use cases for this? |
Sure consider a fullstack project repository including frontend and backend On Wed, Nov 18, 2015, 17:40 Vladimir Starkov notifications@github.com
|
This issue is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Anybody ever figure this out? I am having the devil's own time figuring out how to overtly set the destinationPath on a subgenerator |
|
This doesn't seem to be working for me. yo@next-4. After passing |
@kalbert312 please open a new bug report specifying which generator version you are using. |
Worked for me with this code: this.composeWith('my-generator', {
destinationRoot: this.destinationRoot('sub/folder')
}); |
I have done some quick search among the submitted issues, but didnt find anything about passing a specific
destinationPath
when we call the#composeWith()
method that makes the value local to the sub-generator.I am trying to find the best way to reuse as many existing generators as possible but here it is I am facing an issue, most of the generators cf.
generator-travis
will generate their files based on its defaultdestinationPath
path.It's right we can still redefine the
destinationPath
thanks to#destinationRoot()
method but it could quickly become error-prone since it remains a global value to the whole generators (composed one too).The
RunContext
design calls the generator methods according to ordered groups (default, writing, …), meaning if set a path at the top of the run-loop and set another path meanwhile we will get a collision and only the last one will be considered, the explanation is a bit confused but I guess you are getting the point.For the yeoman designers, do you think it could be a valuable enhancement ?
The text was updated successfully, but these errors were encountered: