Integrate VueJS blueprint as a mainline generator (like Angular and React)

[cmoine]

Overview of the feature request

The actual flow for VueJS is awkward (CLI and https://start.jhipster.tech/#/generate-application as well):

• Choose React/Angular generation
• THEN choose VueJS blueprint

Moreover the web site claims: Spring Boot + Angular / React / Vue Web applications I think it is very frustrating/confusing that we cannot choose VueJS instead of React/Angular. I am pretty sure some users just give up after that and do not dig deeper.

Motivation for or Use Case

VueJS is really gaining popularity, it really makes sense to do it. Some recent articles are now only comparing React and VueJS, Angular is no more part of the comparison :-(

Moreover, I think the VueJS generator would gain popularity and stability since it would be part of the release train. At the moment, a new JHipster version does not imply the blueprints have been tested against it (from JHipster perspective) (tell me if I'm wrong).

Related issues or PR

None, but I would be glad to contribute for this feature in a PR.

[pascalgrimaud]

It's an important discussion cc @jhipster/developers Plz, vote the original ticket with +1 or -1

[wmarques]

I'm ok for merging Vue, the blueprint is quite stable and very well made :)

Just one thought about that quote:

VueJS is really gaining popularity, it really makes sense to do it. Some recent articles are now only comparing React and VueJS, Angular is no more part of the comparison :-(

Both 3 frameworks are made to build applications, if you do shitty things with Angular, ofc the app will suck, same goes for Vue and React. Both have pros/cons, I always see the 3 frameworks on "comparison articles". Angular is very widely used especially in the Java ecosystem.

I agree that Vue is great etc, I even use it myself for small personal projects, but don't discard other technologies because they do have less Github stars or less representation in articles, that doesn't mean anything.

I would have said the same for React of course.

[mraible]

I do a lot of presentations to Java developers around the world. In my opinion, that's the target audience for JHipster. I usually survey the audience to see what frameworks they're using. Angular and React are usually tied in the number of users they have. Vue.js is hardly used by anyone in comparison. Usually just 2-3 hands go up.

IMO, Twitter and the internet (+ who you follow) make Vue seem popular, but it's enterprise usage is still quite low.

On Oct 8, 2019, at 08:22, William Marques notifications@github.com wrote:

 I'm ok for merging Vue, the blueprint is quite stable and very well made :)

Just one thought about that quote:

VueJS is really gaining popularity, it really makes sense to do it. Some recent articles are now only comparing React and VueJS, Angular is no more part of the comparison :-(

Both 3 frameworks are made to build applications, if you do shitty things with Angular, ofc the app will suck, same goes for Vue and React. Both have pros/cons, I always see the 3 frameworks on "comparison articles". Angular is very widely used especially in the Java ecosystem.

I agree that Vue is great etc, I even use it myself for small personal projects, but don't discard other technologies because they do have less Github stars or less representation in articles, that doesn't mean anything.

I would have said the same for React of course.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cmoine]

I don't want to compare those technologies here.

I am just talking about popularity. I hate React, and yet it is the mostly widely used :)

Vue.js is hardly used by anyone in comparison.

Ok that is interesting. However, do you make presentation really worldwide, or mostly Europe for instance?

You are right, big compagnies use a lot Angular and React, but I think that lots of startup opt for VueJS, because much lighter to start with. And I think that JHipster is very useful for startup who wants to start really fast... Big companies develop their own ecosystem. That is my opinion of course ;)

[mraible]

My presentations this year have been in North America, Europe (Spain, UK, and Ireland), and India. I hope to add Australia, Japan, and more Asian countries in 2020.

Do you hate React because you used it on a project and it failed or because you don't like how it works? Just curious as to where your bias comes from. Personally, I like all three frameworks.

[cmoine]

Do you hate React because you used it on a project and it failed or because you don't like how it works? Just curious as to where your bias comes from. Personally, I like all three frameworks.

I (tried to) use it only personally. I hated it because I found tons of boilerplate code, 10.000 ways to do the same things (I guess it leads to very messy projects), and not very abstract... I was happy to see some other people were also allergic to it as well ;)

[murdos]

Big companies develop their own ecosystem. That is my opinion of course ;)

Big companies also use JHipster a lot.

[deepu105]

I'm ok with merging the blueprint. I don't think we have any reason to do comparisons and stuff. In general, React is the most popular lib followed by Vue and Angular, but within the JHipster community usage of Vue might be less. I personally like React followed by Vue, Angular is kind of loosing out to these.

For now, it makes sense to offer all 3 options

[vishal423]

I believe we should also consider maintenance overhead. I have observed less community interest to maintain react than the angular.

[atomfrede]

It would ge good to have vue in the main generator, but currently I see one huge issue with that. It is the protractor for e2e testing. We always try to follow best practices and choose the best tool for the job but in that case I think we could do better from a vue point of view.

So first we need to update the blueprint and get our ci up and running reliable again before continuing here. In general regarding the fact jhipster online does not support the official blueprints I currently don't see a huge issue with that, but when node, .net and maybe micronaut gain traction it would be awesome to select them in jhipster online too.

[vishal423]

So first we need to update the blueprint and get our ci up and running reliable again before continuing here.

That's what I am concerned about. I see no/little active participation by the community to fix broken builds. If we think that the migration to cypress or moving that code to the main generator will help improve on this situation, then, we can try that as well.

On a personal note, I also think about moving react code as a separate blueprint and support only Spring/Java and Angular as the first-class citizen.

[avdev4j]

For me, it's the way to go to. so +1.

[deepu105]

@vishal423 I think the reason is that we have more people in the core team interested in Angular than React. Earlier I was the one maintaining React as I built that part but then later there were few others. But IMO React is still a better option than Angular.

[deepu105]

If protractor is becoming a bottleneck, then may be lets reconsider moving to Cypress

[clementdessoude]

Hi everyone !

I'm not sure that the main concern here is Protractor, but the increasing complexity of combinations offered by JHipster.

Just to let you know, I tried to create a module for Cypress, but was blocked with two issues:

• you cannot simulate typing in "datetime-local" fields yet (https://github.com/cypress-io/cypress/issues/2613)
• I wanted to modify some angular/react/vuejs templates to create a good module, which is not possible to do inside the module (I created some branches in my generator-jhipster fork to test that)

I also wanted to focus more on prettier-java so I stopped working on this lately, but I would like to work further with this in the future.

PS: here is my repo, for those interested: https://github.com/clement26695/generator-jhipster-cypress

[vishal423]

@deepu105, that was my personal opinion after working on both angular and react projects. I still use react occasionally on some small projects, but, in those, favor standard JS over TS :smile:

Supporting multiple front end implementations might impact/delay introduction of new features on backend. As an example, if we plan to support aggregates, then, those would also require UI changes on angular, react and vue and I am not sure if a contributor would like to do that.

[cmoine]

I'm not sure that the main concern here is Protractor, but the increasing complexity of combinations offered by JHipster.

I totally agree we need to be careful with this point.

If protractor is becoming a bottleneck

I think it becomes out of the topic. Fixing e2e tests is a prerequisite, fine. I am not very familiar with e2e tests in JHipster: are they all the same, or do they depend on Angular/React? Would a requirement be that we would prefer Cypress over Protractor only for VueJS? Shouldn't we focus on "technical" requirement instead of technical problems themselves?

[deepu105]

If Cypress makes our e2e more stable then I'm fine to move to it fully. Ideally we should have same e2e test suite for all framework. Thats why we put in effort to render the sme final HTML from Angular and React. We should do the same for vue as well, it means using same id, name, class names and structure. So that we can use the same e2e test templates for all of them

Thanks & Regards, Deepu

On Wed, Oct 9, 2019 at 12:11 PM Christophe Moine notifications@github.com wrote:

I'm not sure that the main concern here is Protractor, but the increasing complexity of combinations offered by JHipster.

I totally agree we need to be careful with this point.

If protractor is becoming a bottleneck

I think it becomes out of the topic. Fixing e2e tests is a prerequisite, fine. I am not very familiar with e2e tests in JHipster: are they all the same, or do they depend on Angular/React? Would a requirement be that we would prefer Cypress over Protractor only for VueJS? Shouldn't we focus on "technical" requirement instead of technical problems themselves?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10575?email_source=notifications&email_token=AAIOKF3FNUUKPSB42A77NXLQNWU4HA5CNFSM4I6RKRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAXMDGI#issuecomment-539935129, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIOKF2ZUWT2N76CVGZA3H3QNWU4HANCNFSM4I6RKRIA .

[jdubois]

I just did a VueJs app and really loved it. For my personal use, this would be my favorite framework today, so I'd be happy to see this merged. Then, I agree with @mraible that enterprise adoption seems very low.

[RothAndrew]

+1 for the idea, -1 for having to slog through a bunch of comments that amounted to "The framework that I like is better than the framework you like".

[yacosta738]

I would very much like to see VueJS integrated into the main project. Vuejs is gaining popularity and is very easy to use. It would also be ideal to have the option of choosing any of the three frameworks (angular / react / vuejs). I hope it can be posible. I would also like to see kotlin integrated in the main project

[TonyLuo]

vue 3.0 Pre-Alpha has been released. is it the time to integrated vue 3.0 into the main project? https://github.com/vuejs/vue-next

[pascalgrimaud]

No, the migration to vue3 won't be done as it is still in alpha

[sendilkumarn]

I really love the idea of putting all three frameworks in the main generator. My only concern is about the overhead that it will add (both in maintaining it and to our pipelines).

I think we can wait a bit to see whether the usage of VueJS (within JHipster context) goes beyond a certain level (like more than 25% users) use VueJS. Then we can decide on moving that into the main generator.

A fun hacktoberfest idea: The prompts should intelligently fetch options from the official blueprints. This will enable us to add vueJS as an option dynamically.

[PierreBesson]

I would argue that vue is already overtaking react while still being a blueprint which is impressive !

As for dynamically adding options, it's obviously not feasible as a new version of the core can break blueprints (and often does). Also if it is in the official prompt why not move the code to the core repo so that we can end to end test it and prevent regressions.

[sendilkumarn]

vue is already overtaking react

😉 😛 I want to tweet this 😉 😛

it's obviously not feasible as a new version of the core can break blueprints

I agree, infact Kotlin sub-generator is broken with every new release. But if we have/get a better solution, then I am all for it.

Also if it is in the official prompt why not move the code to the core repo so that we can end to end test it and prevent regressions.

I am 100% in favour of moving the code to the core. I obviously want that to happen. But our end-to-end tests are flaky now and adding another framework will definitely increase our time spent on CI/CD. I want to address them before moving that to core.

[PierreBesson]

I am so sad for you that the Kotlin blueprint gets broken so often. It's not deserved for all the hard work you put into it. @jhipster/developers I think it should be our number 1 priority to fix this issue as this is impeding the viability of JHipster as an extensible platform. In the past I suggested that blueprints should be able to pin the version of JHipster it uses. However it might be too limiting for some blueprint that modify only a few subgens. A new (crazy) idea I have had recently is to somehow publish all core JHipster subgens as an npm modules and then blueprints would be able to swap them with custom replacements through some kind of dependency injection mechanism. However the "interface" of a subgen would need to be much more strictly defined, maybe through a typescript typings file. I'm not sure if my idea is clear, feel free to ask me more questions. Maybe this discussion can lead to an RFC.

[deepu105]

The problem is regardless of the approach unless we follow a strict backward compatibility approach stuff will be broken, especially changes to templates. We are not breaking our public API often so blueprints shouldnt have much issue with that, and so far I have not seen anyone complaining about API or subgen interface. The real problem is when we change template files, especially when we rename or remove/add files. So unless we have a way to avoid such changes or keep them backward compatible, there will be issues for the blueprint regardless of the approach.

Thanks & Regards, Deepu

On Tue, Oct 22, 2019 at 11:57 PM Pierre Besson notifications@github.com wrote:

I am so sad for you that the Kotlin blueprint gets broken so often. It's not deserved for all the hard work you put into it. @jhipster/developers https://github.com/orgs/jhipster/teams/developers I think it should be our number 1 priority to fix this issue as this is impeding the viability of JHipster as an extensible platform. In the past I suggested that blueprints should be able to pin the version of JHipster it uses. However it might be too limiting for some blueprint that modify only a few subgens. A new (crazy) idea I have had recently is to somehow publish all core JHipster subgens as an npm modules and then blueprints would be able to swap them with custom replacements through some kind of dependency injection mechanism. However the "interface" of a subgen would need to be much more strictly defined, maybe through a typescript typings file. I'm not sure if my idea is clear, feel free to ask me more questions. Maybe this discussion can lead to an RFC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10575?email_source=notifications&email_token=AAIOKF2NDFY2EWWGQ7PGOLDQP5ZLVA5CNFSM4I6RKRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB7LALY#issuecomment-545173551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKFZQ4OA6UB3G5MCF3NLQP5ZLVANCNFSM4I6RKRIA .

[deepu105]

IMO we should brainstorm together during our contributors retreat that we were thinking of doing next year to find a solution for this issue

Thanks & Regards, Deepu

On Wed, Oct 23, 2019 at 9:39 AM Deepu K Sasidharan d4udts@gmail.com wrote:

The problem is regardless of the approach unless we follow a strict backward compatibility approach stuff will be broken, especially changes to templates. We are not breaking our public API often so blueprints shouldnt have much issue with that, and so far I have not seen anyone complaining about API or subgen interface. The real problem is when we change template files, especially when we rename or remove/add files. So unless we have a way to avoid such changes or keep them backward compatible, there will be issues for the blueprint regardless of the approach.

Thanks & Regards, Deepu

On Tue, Oct 22, 2019 at 11:57 PM Pierre Besson notifications@github.com wrote:

I am so sad for you that the Kotlin blueprint gets broken so often. It's not deserved for all the hard work you put into it. @jhipster/developers https://github.com/orgs/jhipster/teams/developers I think it should be our number 1 priority to fix this issue as this is impeding the viability of JHipster as an extensible platform. In the past I suggested that blueprints should be able to pin the version of JHipster it uses. However it might be too limiting for some blueprint that modify only a few subgens. A new (crazy) idea I have had recently is to somehow publish all core JHipster subgens as an npm modules and then blueprints would be able to swap them with custom replacements through some kind of dependency injection mechanism. However the "interface" of a subgen would need to be much more strictly defined, maybe through a typescript typings file. I'm not sure if my idea is clear, feel free to ask me more questions. Maybe this discussion can lead to an RFC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10575?email_source=notifications&email_token=AAIOKF2NDFY2EWWGQ7PGOLDQP5ZLVA5CNFSM4I6RKRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB7LALY#issuecomment-545173551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKFZQ4OA6UB3G5MCF3NLQP5ZLVANCNFSM4I6RKRIA .

[pascalgrimaud]

The issue about compatibility should be reduced, after this PR: https://github.com/jhipster/generator-jhipster/pull/10541

[pascalgrimaud]

To people who think React is better than Angular: can you help on this ticket plz ? https://github.com/jhipster/generator-jhipster/issues/10824 The build for React + sqlfull is broken since long time.

I'm stuck with this, so I can't improve the CI builds to do same tests for Angular / React. Thanks in advance

[deepu105]

I'll try to take a look

On Fri, 29 Nov 2019, 11:02 pm Pascal Grimaud, notifications@github.com wrote:

To people who think React is better than Angular: can you help on this ticket plz ?

10824 https://github.com/jhipster/generator-jhipster/issues/10824

The build for React + sqlfull is broken since long time.

I'm stuck with this, so I can't improve the CI builds to do same tests for Angular / React. Thanks in advance

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10575?email_source=notifications&email_token=AAIOKFY5QLP5XUR23QU4DMDQWGGOZA5CNFSM4I6RKRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFPTAOY#issuecomment-559886395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKF5FYBUFFYTJIB4SKMDQWGGOZANCNFSM4I6RKRIA .

[pascalgrimaud]

I'm adding the label 7.x. Not sure @sahbi-ktifa can take care of this. @nonomoho : as already discussed, do you want take the lead on this ? The goal would be to try to keep git history, so we won't lost the additional contributors

[pascalgrimaud]

@nonomoho : I assigned the ticket to you, as you're a Vue.js expert.

Then, let's add a bounty, if it's more work than expected, I'll increase it later.

[mshima]

@pascalgrimaud I have plans to separate react/angular generators. So if you agree I will make almost every necessary change to vuejs blueprint in preparation for JHipster 7. If it works, it will be just folder move for it to be integrated. This will be the showcase. What do you think?

[pascalgrimaud]

@mshima : just wait a few days, I'll discuss with @nonomoho as he already started this. The main issue is not to move the folder, but to merge the git history, to keep our contributors on Vue.js

[mshima]

Just for information, vuejs structure would change from: generators

• client
• common
• entity-client
• languages

To: generators

• client-vue
• entity-client-vue

[pascalgrimaud]

@mshima : sorry, I don't understand well :) In our generator-jhipster, we already have:

• generators
  • client
    • templates
      • angular
      • react

In vue.js blueprint, we have

• generators
  • clients
    • templates
      • vue

So I don't understand why you want to move:

• generators
  • client-vue

[mshima]

For jhipster 7 I was thinking to propose the following structure:

• generators
  • client
  • client-angular
    • templates
  • client-react
    • templates
  • client-vue
    • templates

Same for entity:

• generators
  • entity
  • entity-client-angular
    • templates
  • entity-client-react
    • templates
  • entity-client-vue
    • templates

I see some benefits:

• reduce conditionals.
• more modular
• allows to create multiples framework for same project.
  • mobile/desktop
  • evaluate toolkits
  • unified CI for every framework.

I have a generator-jhipster branch with the necessary modification to allow client blueprints with this structure.

[pascalgrimaud]

@mshima : I'm fine with this. But don't start the work too early, just wait the official launch of v7 branch... we should discuss about it in our Mailing List

[deepu105]

I don't see how the proposed structure reduces conditionals and help in modularity. May be you need to write a clear proposal first so we are all on the same page. I switched to current structure from something similar to you proposed to reduce duplication and increase modularity originally

On Mon, 24 Feb 2020, 8:40 am Pascal Grimaud, notifications@github.com wrote:

@mshima https://github.com/mshima : I'm fine with this. But don't start the work too early, just wait the official launch of v7 branch... we should discuss about it in our Mailing List

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/10575?email_source=notifications&email_token=AAIOKFYVNLA76FXR45JU333REN2XLA5CNFSM4I6RKRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMW3NJQ#issuecomment-590198438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKFYPIPNN7KH6MJYCEJLREN2XLANCNFSM4I6RKRIA .

[mshima]

I don't see how the proposed structure reduces conditionals and help in modularity. May be you need to write a clear proposal first so we are all on the same page. I switched to current structure from something similar to you proposed to reduce duplication and increase modularity originally

@deepu105 I was curious about this change but I couldn't find it.

Following https://github.com/jhipster/generator-jhipster/issues/10528 proposal. Only the writing priority should be moved to the client-{clientFramework} priority. To write 2 client framework would become something like: this.composeWith(['jhipster:client-angular', 'jhipster:client-react']);

Needles should be adapted too. But it depends on a yeoman-evironment 3.x and yeoman-generator 6.x

I fell that jhipster-internals is in the limbo right now. Very few developers care about it, and none fell confidence to change/merge changes to it. Ex: https://github.com/jhipster/generator-jhipster/pull/10084, https://github.com/jhipster/generator-jhipster/pull/10527 If you want to discuss jhipster 7 possible changes, I would love to. (ex: jhipster/blueprint versioned auto-install, composed api (ex needles)).

Some of the changes I think that we should do:

• remove configOptions. It causes many synchronization problems between generators.

• create templatesContext to pass to the templates instead of passing the generator. Debugging the entire generator hierarchy is nuts. Just keeping the relevant parts on templatesContext is much easier.

• extract jhipster cli into a separated package for auto-install.

• maybe, instead of merging jhipster-core into generator-jhipster, merge generator-base and generator-private into jhipster-core and rename to generator-jhipster-core (for environment lookup).

Currently I just create the PRs and wait and maybe @pascalgrimaud merges it :P

[pascalgrimaud]

@mshima : it tooks me a lot of time to read all your work and try understand, that's why I didn't merge it quickly sorry... So I can't imagine the time you spend to do all of this, it's just crazy !

[deepu105]

Lets not merge any big changes for the internals now, lets do it for V7. I agree the internals are a mess now due to legacy reasons and backward compatibility and stuff. I agree the blueprints and composability mechanism has to be refactored. But its not an easy task. We need to ensure we don't break modules and blueprints(its really a workaround due to yeoman limitations) and have to ensure composability is working fine. Its been a while since I touched the internals and I guess there has been a lot of changes after my last work there.

If you are willing to work on it, I suggest you first create a ticket and list out changes that you propose. Break them into small units and create PRs again v7 branch so that we can easily review and ensure we are not breaking anything. Please note the test coverage for internals is still not very great that is another reason why I'm less confident of refactoring stuff

[mshima]

Lets not merge any big changes for the internals now, lets do it for V7.

The big refactoring to internals is on hold.

I agree the internals are a mess now due to legacy reasons and backward compatibility and stuff. I agree the blueprints and composability mechanism has to be refactored. But its not an easy task. We need to ensure we don't break modules and blueprints

JHipster 7 will break it.

(its really a workaround due to yeoman limitations)

What workaround due to yeoman limitations? I am the only active yeoman contributor right now. So if you have some ideas, feel free to to tell me.

and have to ensure composability is working fine.

This is the hard one. There is no test case for this one. There is a bug on translation that I know for a few months already:

• If you create a project with translation enabled (answering prompts), not all necessary translation change will be settled at the first run. This is due different generators trying to write to translation needles before the file is written. And the languages are not passed correctly to other generators. As a workaround you have to run jhipster --with-entities

Its been a while since I touched the internals and I guess there has been a lot of changes after my last work there.

I don't think so.

If you are willing to work on it, I suggest you first create a ticket and list out changes that you propose. Break them into small units and create PRs again v7 branch so that we can easily review and ensure we are not breaking anything. Please note the test coverage for internals is still not very great that is another reason why I'm less confident of refactoring stuff

About this, I don't know if this is the best approach. Reviewing this changes is really difficult. What I did at https://github.com/jhipster/generator-jhipster/pull/10696 is to create a test case that compare the source generated before and after the change. Once the new one is identical or have fixes, then it's ready to merge.

[mshima]

@mshima : it tooks me a lot of time to read all your work and try understand, that's why I didn't merge it quickly sorry... So I can't imagine the time you spend to do all of this, it's just crazy !

@pascalgrimaud don't worry about it.

[pascalgrimaud]

I just did a new release of JHipster-VueJs blueprint: v1.9.0, linked to generator-jhipster v6.10.1

For v7, unless someone is against this, I'm starting to integrate Vue.js to main generator-jhipster, and trying to keep git history. @mshima : once it's merged, we will be able to do refactoring, with your suggestion. Hope you're ok.

[mshima]

@pascalgrimaud if you are talking about the project structure, this is not a priority and I don't think I will do it because cypress plans to create a common e2e. With common e2e we will need a client-common and will start complicating too much, let's keep the way it is now.

• If you are talking about the generators refactoring (configOptions), most of it is done https://github.com/jhipster/generator-jhipster/pull/12038. Please consider merging it before starting vuejs integration. I will wait a day for reviews/suggestion and then merge it, the generated source for current integration test cases are identical, it just fixes README.md not generating test (proctractor and gattling) info.

• Create templatesContext is a major change to templates, I will create an issue to track it.

jhispter-cli and generator-jhipster-core ideas are dropped, not worth.

[pascalgrimaud]

yes, I was talking about project structure but if you think it's low priority, so let's forget it.

Then, you're right about #12038 : I'll merge it before starting Vue.js integration

[pascalgrimaud]

The last part was done, related to daily builds :

We can close this ticket