Specify the best generator structure with a RFC then align

[Tcharl]

Overview of the feature request

Most of the generators of the core framework are different:

• Some have some files at the same level of the generator
• Some have logic inside generator.ts
• Some are using support/ folder for phases and helper methods
• Some have command.ts, other not
• Some are using files.ts prompt.ts...
• Some have properties in generator.ts

Would be nice to specify the ideal generator layout and filenames conventions through a RFC.
Alignments may be eligible to bounties then

Motivation for or Use Case

Clearly define the conventions of the core generators

• Checking this box is mandatory (this is just to show you read everything)

[mshima]

IMO generators should have 'generator.ts', 'generator.spec.ts', 'command.ts' and 'index.ts' only if possible.
Everything else is optional.

• 'files.ts' and 'entity-files.ts' only if there are many files.
• 'prompts.ts' are for backward compatibility only, new prompts should preferably implemented in command.
• support are for utilities.
• 'types.ts' only if the generator type will be used elsewhere.

If we keep everything inside generator.ts it will be easier to maintain.

[Tcharl]

I do agree with the optionality of files.

Disagrees with generators.ts: it goes against SRP, it does:

• Data mutate
• Helpers functions to be called by generators in the downstream inheritance chain
• Stateful things (many use of this)
• Scheduling (tasks)
• Assertions
• Yeoman magic
• ...

It's against design patterns, SOLID, and a burden to readability and extensibility. Not saying that it should be applied by every blueprint of the community, but the one part of the core classic (generator-jhipster) to ease maintainability

Let me draft the base RFC and exchange around it, I would definitely prefer 5 (optional) packages and tenth of different files with their own, conventioned, purpose per generator than 500+++ lines all in one generator.ts.

Would make more clear where to contribute for a specific concern imho.

https://www.manning.com/books/five-lines-of-code
https://www.geeksforgeeks.org/system-design/solid-principle-in-programming-understand-with-real-life-examples/

[mshima]

Very few generators are complex, in those case are ok to have more modular implementation.

[Tcharl]

I agree most of generators are not complex, but the ones that are not are potentially reused (fully or partially). To me it make sense to get something aligned overall

[mshima]

We should prioritize splitting the entire generator. Like add spring-boot:bootstrap and others bootstrap generators.