Improve the current generator types

[Tcharl]

Overview of the feature request

The goal would be to handle the generator types and host them in their relative owner generators compared to the current situation were all (most) of the types are referenced within a central point.

To schematize the current types to generator relationships in a small sample:

Here, we can notice some drawbacks/surprises for newcomer, and here are the ones that I identified:

• Any other generator (i.e. generator/server, other Client generators like react, any blueprint) are using a type that is extending AngularApplication so every generators will have autocomplete on the attributes of this type even the ones that doesn't need it.
• Also this inheritance chain seems counterintuitive (I always learned at school that 'Circle' extends 'Shape', not the reverse)
• It also creates tight coupling and forces the generators to be released as a big monolith (e.g. if an attribute of CypressApplication is modified, generators/angular should also be released because we cannot guess easily the impact of such a change on the other generators.
• Finally, blueprints, even backend ones are forced to extend generator/client which seems confusing

Proposed solution

At target, the object inheritance could be improved following this approach

This type architecture will come with multiple advantages:
. IDE will autocomplete only fields needed: for example, autocomplete and type of field of AngularApplication won't be available on generator/server
generator/client or generator/base have been modified, but it won't be necessary to release it when generator/server will be modified
. Blueprints will have to extend leaf generators they need (i.e. generator/angular) lowering the need of synchorinzing with the upstream
. SOLID principle and clear separation of concern at all levels
. releases of generators can be modularized, i.e. generator/angular can be released only when generator/angular,

Motivation for or Use Case

• Releasing generators independently
• Locating objects and fields on their own generators
• Respecting SOLID principles
• Modularizing jhipster core: some would just want to consume application generators, others platforms generators, some other only entities, others just extending servers, etc.
• Overall readability

Definition of done

This story will be considered as done when:

• Types will be mostly extracted from 'command.ts' files (+ derived fields)
• Types and fields will be located in the downstream generator in the inheritance chain of templates using it (i.e. entityAngularJSSuffix will be located in generator/angular)
• Types fields will be hydrated and used in the downstream generator in the inheritance chain of templates using it (entityAngularJSSuffix will be hydrated in generator/angular instead of base-application/support/prepare-entity.ts, liquibase* fields is used and hydrated in liquibase generator)
• There will be no cycles between generators anymore: Downstream generator in the inheritance chain can consume methods and types from upstream generator only.
• lib/types do not exist anymore
• IDE autocomplete on generators will only show attributes needed by the current or downstream generators templates on Feature, Options, Config, Source, Application, Entity, PK and Fields
• Downstream generator can be virtually released without the need of any sibling generator
• Generator classes should ideally be stateless (no classlevel field) // this one can be in another issue)
• No field should be duplicated in different types (i.e. customizeTemplatePaths is in Source and not in Application)
• No ts-ignore, no any
• No type concat in generics
• Generator inheritance chain is more hierarchic than flat as now
• Generator Generics are minimized

Additional note

• Part of the bounty can be unlocked at any moment by someone that thinks he contributed enough to claim it
• Bounty can increase over time
• I would personally like this tasks to be solved before v9 because it comes with many breaking changes, and to me is synonym to the survival of the framework until the next major: new big features like Options generation annotations on entities #26007 can only be achieved after this one being done

Related issues or PR

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

[Tcharl]

Here's how I'm trying to bootstrap the story:

1. Implementation of a proof of concept on the 'right' generics and types usage on few high level generators (down to base application)
2. Make the project testable again with the introduction of an opt-in
3. Dumb implementation of the generics on the entire codebase
4. Pass on every Types attributes and try to move the callers on a generator that is lower in the inheritance pyramid in order to reduce the amount of generics
5. Try to make the x-generator.ts stateless to lower again the amount of generics.

Any other suggestion? Any remark?

Otherwise, on the money topic, I'll opencollective either on the 20th of May or either the 1st of June (bank account threshold check)