Generator-jhipster: Override `CLIENT_MAIN_SRC_DIR` in blueprint generators

[danielpetisme]

Overview of the feature request

The global vision would be to permit the override of every file structure related variable.
Personally, for the .Net core blueprint I would like to override the CLIENT_MAIN_SRC_DIR constant to reuse the existing client generator as is and generate the web files into the ".Net" web folder.

Motivation for or Use Case

The folders configured for the clients files are related to the Java ecosystem (src/main/java).
Beyond Java, each community (.Net, Node, etc.) has its own file structure "tradition".

So far the JHipster app structure is managed by a set of constants like MAIN_DIR, CLIENT_MAIN_SRC_DIR, etc. which a blueprint can't override.

Related issues or PR

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

[danielpetisme]

After a quick overview, I think the files.js shouldn't have access to the generator-constants file.
My proposal would be to load the contants in the index.js (ie. the phase generator) and pass them to the writeFile method

This is a high level proposal(I didn't test the following snippet is just to explicit my idea):

# index.js
const constants = require('../generator-constants');

module.exports = class extends BaseBlueprintGenerator {

  _writing() {
        return writeFiles(constants);
  }

}

# files .js

function files(config) => {
  sample: [
        {
            path: config.MAIN_SRC_DIR,
            templates: [...]
        }
  ]
}

function writeFiles(config) {
    mkdirp(config.MAIN_SRC_DIR);
    // write angular 2.x and above files
    this.writeFilesToDisk(files(config), this, false);
}

This mechanism permits to extend/replace the initial constants in blueprint' generators

UPDATE:
It's trickier than that! The path attribute is used to specify where to find the templates and where to produce the rendered file...
In my case I want to keep the original file path (src/main/webapp because I don't plan to copy paste the client files in the generator) but I have to update the destination.

The naive way would be to override the ClientGenerator, retrieve the files object and add a renameTo attribute for each file).

[pascalgrimaud]

I discussed with @BananeGuimauve and I though it was possible to edit these variables but I was wrong.
Maybe @avdev4j you have an idea ? As you're our expert on blueprint

[avdev4j]

As @danielpetisme said

The naive way would be to override the ClientGenerator, retrieve the files object and add a renameTo attribute for each file).

I think it's the easier way since we don't have to modify the generator before.

Also Daniel has right when he said that CLIENT_MAIN_SRC_DIR is used for both reading and writing templates. We used to store templates at the same path than we create it.
Redefine the constant will affect both phases, and we don't want to do that.

But I think we can do a nice thing for that.

1. Update all files.js in generators to create files with a new constant like SERVER_TARGET_MAIN_SRC_DIR which will be initialize with the SERVER_MAIN_SRC_DIR value.

const SERVER_MAIN_SRC_DIR = constants.SERVER_MAIN_SRC_DIR;
const SERVER_TARGET_MAIN_SRC_DIR = SERVER_MAIN_SRC_DIR;

1. Update file definitions to use SERVER_TARGET_MAIN_SRC_DIR

        {
            condition: generator => !!generator.enableSwaggerCodegen,
            path: SERVER_MAIN_RES_DIR,
            targetPath: SERVER_TARGET_MAIN_SRC_DIR,
            templates: ['swagger/api.yml']
        }

1. In our blueprint load files array and redefine SERVER_TARGET_MAIN_SRC_DIR

const serverFiles = require('generator-jhipster/generators/server/files').serverFiles;
const SERVER_TARGET_MAIN_SRC_DIR = "apath/different/from/generator";

const myServerFiles = {
    ...serverFiles
};

Of course I have not tested that for real but I don't see a problem to do that. The main problem is to change the way the generator work to be sure we can redefine the target folder. By doing this we avoiding many re-definitions in blueprints and having a more flexible code.

[danielpetisme]

Looks like we are starting a huge refactoring which will may implies API changes... The jhipster generator is well covered but I'm not sure it's the case for blueprints...
Do we want to be backward compatible ? Should we post on the ML to get more feedbacks on this issue?

[avdev4j]

With my solution (maybe there is another much better) we should not break anything and everything should work like it use too. BUT the risk to do some mistakes is really important and the modifications are quite tricky "only" for a blueprint issue.

We have to balance our choice between the risk and the profit and I'm not sure to be the best person for that, maybe asking the team by ML is a good idea.

[pascalgrimaud]

@danielpetisme @avdev4j : how can we advance on this ticket ? Are we stuck ? Maybe we can add some documentation about that ?

[danielpetisme]

We should have a internal discussion about what's the generator scope.
I don't know how far we want to go on the _variabilization_ of the generator, I can see a risk of transforming the generator into a _yeoman++_ but it's maybe not a bad issue?

[mshima]

Is this still needed?

[danielpetisme]

The issue is more a discussion point.
I don't know how to move on this one.

[mshima]

@danielpetisme I think this is the way to do it: https://github.com/jhipster/generator-jhipster/pull/11337

[mshima]

This is doable.
One problem is the needles that uses generator-constants directly:
https://github.com/search?q=generator-constants+repo%3Ajhipster%2Fgenerator-jhipster+path%3A%2Fgenerators%2F&type=Code
Another is to set maven/gradle to used the custom folder.
Or we should close as lack of interest.

[pascalgrimaud]

@mshima : you're our expert on the blueprint part, so you know better what we should do here :)

[mshima]

@pascalgrimaud one benefit is to build more then one client toolkit (angular/react/vuejs) in the same project.

• Easier to evaluate toolkits.
• Easier to keep feature parity.
• Desktop/mobile toolkits.

This isn’t difficult, but I am currently lacking of motivation. :p

I will implement it, this will load a kind of a 'config file' from the blueprint.

[pascalgrimaud]

@mshima : you already did an amazing work on blueprint recently, so I totally understand. So for me, it's not a blocking issue as in blueprint or module, we could do what we want !

[pascalgrimaud]

I'm adding a 1st bounty on this as I saw the amount of work to achieve this.
If you think it's not enough, just tell me @mshima and I will increase it.

[mshima]

@pascalgrimaud it’s done.

[pascalgrimaud]

Increasing the bounty because the amount of work here