Skip to content
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

Closed
canercandan opened this issue Nov 16, 2015 · 12 comments
Closed

Comments

@canercandan
Copy link

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 default destinationPath 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 ?

@SBoudrias
Copy link
Member

For the yeoman designers, do you think it could be a valuable enhancement ?

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 fs methods with paths relative the the current working directory. To allow destination root to work, we had to bind this virtual path with the actual CWD.

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 generator-travis to take a path parameter and base themselves of that path to know where to generate their files.

@SBoudrias SBoudrias added this to the 1.0.0 milestone Nov 16, 2015
@canercandan
Copy link
Author

@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.

@iamstarkov
Copy link

@canercandan can you give me some insight why do you need this feature?

@canercandan
Copy link
Author

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:

/folder1/.travis.yml
/folder2/.travis.yml

The easiest way to accomplish this is by adding a path option in the used generator in order to set the destination path of the copied file.

@iamstarkov
Copy link

okay, is there any real life use cases for this?

@canercandan
Copy link
Author

Sure consider a fullstack project repository including frontend and backend
(client and server).

On Wed, Nov 18, 2015, 17:40 Vladimir Starkov notifications@github.com
wrote:

okay, is there any real life use cases for this?


Reply to this email directly or view it on GitHub
#872 (comment).

@github-actions
Copy link
Contributor

github-actions bot commented Jan 1, 2020

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

@github-actions github-actions bot added the stale label Jan 1, 2020
@github-actions github-actions bot closed this as completed Jan 6, 2020
@res63661
Copy link

Anybody ever figure this out? I am having the devil's own time figuring out how to overtly set the destinationPath on a subgenerator

@mshima
Copy link
Member

mshima commented May 27, 2020

this.composeWith(gen, {destinationRoot: subDir})?

@kalbert312
Copy link

kalbert312 commented Mar 23, 2021

this.composeWith(gen, {destinationRoot: subDir})?

This doesn't seem to be working for me. yo@next-4. After passing { destinationRoot: this.destinationPath("client") } to my subgenerator compose calls the subgenerators are still running in the original this.destinationPath

@mshima
Copy link
Member

mshima commented Mar 23, 2021

@kalbert312 please open a new bug report specifying which generator version you are using.

@robinmanuelthiel
Copy link

Worked for me with this code:

this.composeWith('my-generator', {
  destinationRoot: this.destinationRoot('sub/folder')
});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants