What is the importance of the `app` sub-generator in a blueprint

Question

I've got a mostly working blueprint for internal use-cases. Lots of opportunity left. However, the need or use of the app sub-generator is not clear during blueprint generation. It is is one of many options in the subgenerator selection and the available documentation makes no mention of it.

Many of the cited examples use an app module. Some very lightly, some a little more. Where does it fit in the generator lifecycle? Is it the elusive application loaded throughout the examples?* If so, why the name? There's a cognitive disconnect.

* I have questions about the use of the application object, e.g., async writeTemplateFiles({application}) { ... }; any use of it breaks snapshotting in my blueprint. WebStorm can't even resolve its origin. I have combed so much of the code looking for the import or inheritance tree.

Answer 1

The app generator is not mandatory but it is the entry point for JHipster to initialize the generation process. app as entry point is the yeoman convention and there is no reason to change it.

That been said, adding a app blueprint will depends on the use case. There are 2 kinds of blueprints, Side-by-side and normal blueprints.

This use case is for internal use, so I am supposing every application will use the same features.

• Side-by-side blueprint will not change the original generator workflow. So the generator that will be implemented is for organizational purpose. There is little to no difference which generator you use. (If you plan to change different JHipster features, it's better to implement where JHipster implements.)

• Normal blueprints will halt the original blueprint. Every task should be reimplemented by inheritance. The app importance in this case is that you can force to never generate a frontend or a backend.