Closed arjunnayak closed 4 years ago
Not sure, I think it has been already asked but I didn't find the ticket or the comment. Maybe do you remember @avdev4j or @murdos ?
I don't think we have a ticket for that. I remember a private discussion about doing a blueprint for app generator. One solution invoked was to do our own app sub generator. TBH I did not try.
I understand your problem @arjunnayak I have the same one for a company blueprint. But I wonder if it's really the goal of blueprints. What do you about that @deepu105?
I'm a bit puzzled with this request (and I don't remember having already discussed it): by overriding the app subgenerator you can really change the full jhipster behavior, since this subgenerator is orchestrating the other subgenerators (common
, server
, client
, ...).
But why not, we could try. I also wonder what @deepu105 thinks about it.
As mentioned in the description, our main concern is simplifying the prompts. At this time, we don’t have other needs to override the app generator. For example, we have our own front end generator based on create-react-app, so there’s no need to even prompt for application type since our blueprint is only used for generating micro services.
Is it possible to move these prompts to a separate generator? That may lessen the potential for messing up crucial functionality happening in the app generator. Just a thought
having pre and post prompt sub generators could be a way to do this.
Another solution for you could be having your own jhipster online (the original one is open source too) and remove the fields you don't need (application type for exemple) then it generates a .yo-rc.json and call your blueprint. Every prompt you want to skip will be fill up in the .yo-rc by the jhipster online. I assume it change the way you use your generators.
Hello, We potentially have a similar issue in our company and I think at least being able to limit the type of application or other options in the app sub-generator could be useful. At the moment we are focusing on building micro-services using JHipster and the blueprint technology, and being able to at least fix the type of application our customers will build could help in reducing a bit of potential confusion.
After thinking more about it, I think we should do it. I'll probably work on it and give it a try in the next days.
@murdos which of the two approach are you talking about? being able to override steps in the app-generator and give full control to the blueprint author or just limit certain options?
Give full control, by making app
subgenerator overridable like other subgenerators such as server
, client
, ...
thanks @murdos I changed the label and assigned the ticket to you
Thanks @murdos, let us know how we can help!
@murdos do keep in mind that app generator is the main entry point which composes others so extending it could be tricky. If you need any help let me know
FYI I just unassigned from this ticket since it's indeed more tricky than what I initially thought and I don't plan to work on this soon.
Hi all, As said @deepu105, is too complicated and can bring errors for the developer, because the app generator controls all subgenerators. So I have a custom solution that you can implement (that I have tried) in your blueprint: As preconfiguration before starting jhipster, you can create a yo-rc.json with the answers for the prompts that you don't want to show. So you can create and show your custom questions in whatever order.
However, we can do that as option in the jhipster cli instead to implement it in all blueprints: we can run jhipster with (for example) --add-yo-rc option, in order to give a specific yo-rc.json path, specially for the first generation (or the second that overrides that created before in the generation folder)
My easy solution for the app generator customization is in #10482
Overview of the feature request
While we can extend majority of the sub-generators in a blueprint, it would be great to have the option to extend the others, namely the app generator.
Motivation for or Use Case
In the interest of developer experience at our company, we're trying to simplify as much of the blueprint process as possible. In our case, this involves making modifications to questions that we can't control like type of application, internationalization, testing frameworks, installing other modules from jhipster marketplace, etc. Is this possible, or is there a technical limitation around this?
Related issues or PR