Allow Jhipster blueprint breaking API change post 8.8.0

[Tcharl]

Hi,

8.8.0 has been published, and it seems to be time to prepare for V9.

I propose to allow blueprints breaking API change as of now in order to offer flexibility for core developer to improve the core of the generator.
Let's communicate that this current version is the last 'stable-APIzed' one until the 9th in order to get a good period of time for in depth core refactor.

Overview of the feature request

There are many things that should be done that needs some 'plugin' contributor breaking change and that will greatly improve the readability (and velocity) on the current codebase, to list a few:

• Moving types on their respective generators, i.e.
  • making generator-server to extends BaseGenerator<ServerApplication> instead of a generic Application to have it (and only it) being able to use Server attributes in its injected applicationobject.
  • It will also have as a nice side effect to have all generators depending on base to not reference any high level generator (having any client reference the server by transitivity is a nonsense) fold this import
  • it will come with a straightforward dependency tree and not a circular one see for more details
• Rely on command.ts structure for types instead of duplicating the work.
• Use release management per generator instead of a global one: following practices of angular and react, being able to release @jhipster/server independently of @jhipster/generator-base
• Move some methods and fields which are not really on their right generators or place ([i.e. reference to server in common gen] (

  generator-jhipster/generators/common/generator.ts

  Line 162 in 2243f1b

  SERVER_MAIN_RES_DIR,

  )
• Move jdl entries in their respective generators
• Cleanup the amount of generators and others lib, utils folder which makes the codebase blurry
• Get rid of cjs
• Fully move to typescript and strong typing everywhere in the codebase
• Get rid of some legacy properties (i.e. generator.context and switch to full application type)

Motivation for or Use Case

• IMHO Jhipster needs a bit of API and codebase cleanup in order to be more bugfree and easy to contribute
• There are a lot of discussions in PR since month regarding breaking changes
• When we take a look at the list of blueprints in Github, there are no blueprints outside of the ones of the jhipster community that are updated (and working) since the last 7 months.
• Traction is going a bit down due to the lack of new contributors (due to codebase complexity), configurabilty (which is not that much possible due to the codebase qwirks), and fancy new patterns (like CQRS, CDC sync, ...) see

What do you think, do you agree?

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

[mshima]

• Moving types on their respective generators, i.e.

Types are not stable, they are not frozen.

• Rely on command.ts structure for types instead of duplicating the work.

Types are not frozen.

• Use release management per generator instead of a global one: following practices of angular and react, being able to release @jhipster/server independently of @jhipster/generator-base

I don't agree we should modularize packages for v9. I will increase maintenance burden.
Monthly releases that follows Spring Boot release schedule is good enough for us.

• Move some methods and fields which are not really on their right generators or place ([i.e. reference to server in common gen] (

  generator-jhipster/generators/common/generator.ts

  Line 162 in 2243f1b

  SERVER_MAIN_RES_DIR,

  
  )

This is a minor compatibility field.

• Move jdl entries in their respective generators

Not a breaking change.

• Cleanup the amount of generators and others lib, utils folder which makes the codebase blurry

Not a breaking change.

• Get rid of cjs

We only have cjs in binary and support cjs configs in blueprints.
I don't think there is something to do right now.

• Fully move to typescript and strong typing everywhere in the codebase

Not breaking

• Get rid of some legacy properties (i.e. generator.context and switch to full application type)

It's not legacy. Just a different approach.

I don't think we should start v9 beta now, I think we should follow node schedule and start v9 once node 18 is EOL.
IMO we should just follow deprecation standards for now.

[Tcharl]

Hi @mshima, thank you for your message.

Types are frozen in a way: we can of course modify them without considering that it is breaking. Still, we cannot modify the application, entity or field object injected at each stage of a generator.

To illustrate it:
Currently, when I inject the application object in a client generator step (of any other leaf like angular, react, vue), I have inference on cacheProvider, productionDatabase, ... Because the application object injected is of type ApplicationType which extends ServerApplication & ClientApplication & more.... Changing this inheritance chain to be accurate on each generator would definitely lead to many breaking changes in the codebase.

Use release management per generator instead of a global one: following practices of angular and react, being able to release @jhipster/server independently of @jhipster/generator-base
I don't agree we should modularize packages for v9. I will increase maintenance burden.
Monthly releases that follows Spring Boot release schedule is good enough for us.

I'm not saying that v9 should be modular, I'm just asking to get an accurate, easy to read, root to leaf generator dependency tree instead of the current cyclic graph for V9 to prepare a potential modularization if we identify a value doing so. Clean top to bottom tree, generators clear separation of concern is a nobrainer.

To be clear on the requirement with a concrete example:

• generator-base should import from nowhere else compared from current situation.
  • the current situation is that from here you cycle to an object which extends an object definition which should be owned by the other generators (server, client, spring-boot, ...)
• generator-git should be self-sufficient (containing cli, jdl, command, type, generator, templates, support, ...) and only have a dependency to generator-base.
• So that one day, we may choose to release it independently, or consumer may choose to use it standalone
• And for sure, anyone wanting to enhance the git support won't have to read and understand the entire jhipster codebase to contribute, which will be a big step forward.
• This feature may also simplify the overall readability of the codebase because it forces to use application and entity attributes on the right generator (close to the command which contains it) which I hope will lead to drastic code improvement.

Question

What's remaining before V9? What are we waiting for in term of big dependency upgrade, feature to provide, ...?