Feature Set, Vue CLI and some general question about jhipster-vuejs

[deepu105]

First lets migrate the default monolith app to Vue so that the default options are supported to begin with. Once thats done we can start implementing additional options. Does everyone agree? If so we can create new tickets and decide who will do what.

[deepu105]

I agree with most of it and let's start with what @sahbi-ktifa has. Let's go with what is most used in the Vue community. I think its good to start with VueX as most of the real-world use cases would end up needing some state management. If Vue CLI is useful let's use it but we also need to ensure that the Vue support closely follows Angular/React as well to avoid defragmentation.

Regarding TS vs JS, though I was not a fan of transpiling type systems, after using TS for almost a year I really like it (when used practically and not being a type nazi) its really helpful in code management/refactoring etc and I guess will help our community which is mainly back-end people. SO if possible I would like to stick to TS as we do the same for Angular and React. And as @sendilkumarn pointed out if Vue 3 is gonna focus on TS then as Hipsters we should start that already 😉
btw @sendilkumarn can you share some link on the news about TS focus on Vue?

[hdurix]

I currently work on a Vue.js application integrated with JHipster as well. Here are the technologies we chose:

• Vue CLI (really useful and we didn't notice any limitation until now, webpack can still be configured for extra needs), it could be the good project to try to use a CLI and see what solution is best.
• Typescript (it does work very well with Vue, expect it sometimes needs a few tweaks, especially for unit tests) & TSLint
• Jest for unit tests (coverage is well integrated with Vue CLI, as opposed to mocha + chai solution / however some troubles with cache)
• Cypress for e2e tests (no problem using it, it works like a charm)
• Axios for HTTP requests

[sahbi-ktifa]

I created a sample jhipster project, redoing all components as Angular ones :

• I used Axios as recommended by Vue documentation for http request
• Vuelidate for form validation
• VueI18n for dynamic translation
• VueCookie ans VueX to maintain app state
• Webpack configurations were inherited from vue-cli but can clearly be enhanced
• Finally, I did not used TypeScript but regular JavaScript

I should add my work on a fork to let you review it (of course, it's only a draft at the moment, and should be challenged). I'll do it asap.

[sendilkumarn]

@sahbi-ktifa I too agree that we will start with js and then gradually move towards ts
I would say ver.1 can be in js and then change to ts later.

[Gnuk]

There is a discussion to know how to have official Vue CLI documentation on integration with backend frameworks.

I think we could participate to this discussion with the Vue.js community to help them or propose a standard documentation to have Vue CLI with Spring Boot like we'll do with this feature.

What do you think about this suggestion ?

[jdubois]

@Gnuk yes, definitely +1
VueJS looks like a much nicer project than Angular (I don't know for React), from what I see they are trying to work with third-party projects, and that's awesome. I'll answer on their thread.

[gurbirdhillon]

Here are my thoughts:

• Vue-Cli is good as it can take care of lot of boiler plate setup.
• VueX is nice to have but don't really essential.
• I would also go with plain javascript instead of typescript (preferred by VueJs community)
• Axios is also my fav for http request.

I also like @sahbi-ktifa ‘s setup.

[atomfrede]

Sounds great. We are using a similar stack except VueX as we have quite small micro frontends so not much state management required. I would also go with plain javascript instead of typescript 👍

[sendilkumarn]

I like @sahbi-ktifa setup, it does cover most of our wanted features.

Vue-CLI is a good option, but based on our experiences / discussions / opinions with Angular CLI and CRA. Let us not take that.

👍 for JavaScript but Vue 3 will have a complete focus on TypeScript (so we will surely have a discussion that time whether we want to switch to that) - Just a heads up.

[gurbirdhillon]

Here is quick read/benefits for using vue-cl version 3.
https://medium.com/the-vue-point/vue-cli-3-0-is-here-c42bebe28fbb

[deepu105]

In that case we could use Vue CLI with typescript

[atomfrede]

+1 so Vue CLI with typescript, jest and cypress and tslint it is.

[deepu105]

For e2e wouldnt it be easier to just use the protractor tests from the react client as I believe it can just work as it is without any major change

[hdurix]

I agree with @deepu105, if the couple vue+protractor is working, we should use protractor instead of cypress.

[atomfrede]

Let's see how it works. I would suggest lets start and maybe give cypress a try as it is the preferred solution in the vue community, so if it works we don't need to maintain special configuration for protractor (writing tests is imho easiert) and we can rely on the power of the vue community and it might attract more vue developers to contribute (maybe).

[deepu105]

@atomfrede I was thinking of a quick win so that we can reuse the same templates from React instead of maintaining another set of templates. I was even thinking of moving all the e2e tests out and reusing the same for Angular and React since they are pretty much similar

[atomfrede]

@deepu105 Yes makes totally sense. Maybe just let's get started and not too much thinking about what we use for e2e testing now and decide when we need to. There is much work we need to do before.

[Gnuk]

I work currently with @hdurix on a JHipster and Vue.js project.

We use all Vue.js features he said but also:

• Pug templates because it's very succinct, so I think it's interesting to let people use it but not force them.
• Separate Pug and TypeScript files on .vue components.
• VueI18n for translations

We don't use style on the project because we create a pattern library but in this library, we use the preprocessor Sass with dart-sass wich is now the official implementation of Sass.

The webpack configuration exists since August 1, 2018 and it's planned on Vue CLI.

I think Sass is a good preprocessor but I think there could be an option to choose what we want like in Vue.cli. But if it's too complicated to add options on this part in a first version, I think it could be interesting to prefer Sass with SCSS syntax because it's CSS compatible.

We also use stylelint in addition as a CSS linter with SCSS config recommendation scss-config-recommendation.

About Cypress, I think it's really good because it's easy to use with response stubbing and protractor is not officially supported by Vue.js.

Overall, I think Vue.js is currently used differently between the community and It will be better if JHipster let the ability to keep a flexible Vue.js environment. I think it could be really interesting to open Vue.js project in Vue CLI using vue ui and debug using Vue.js devtools.

[Gnuk]

@deepu105 In the Vue.js #q-and-a Discord channel, you can read it:

evan Hier à 18:26
@George Vue core will be refactored to use TypeScript. In that process we also plan to improve general type-friendlyness of the APIs.
^ that's for v3

[deepu105]

@Gnuk thanks for the info.

I think we shouldn't overcomplicate stuff. Lets stick to options that are available in JHipster to start with so the stack would be

• VueJS written in Typescript
• Jsx or html for templates
• Vuex
• Vue Router
• Vue CLI
• Axios
• Vuei18n
• Sass and css options (css can be later and Sass can be default for now)
• Jest
• Protractor if it works without any additional work else we can switch to Cypress
• Tslint , prettier

[Gnuk]

Except I don't know how it's difficult to have both Tslint and prettier (cf this issue), i agree with it.

[sahbi-ktifa]

I agree too.
Should I still make my work available as a blueprint even if it's only a start using JavaScript or should we rewrite it from scratch using TypeScript and all the above? If so, I'll wait for tickets 😉

[deepu105]

I think your work should be good starting point. We can simply rename file extensions first and should just work fine

…

On Sun, 19 Aug 2018, 9:28 am Sahbi KTIFA, ***@***.***> wrote: I agree too. Should I still make my work available as a blueprint even if it's only a start using JavaScript or should we rewrite it from scratch using TypeScript and all the above? If so, I'll wait for tickets 😉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDlF0ps0ttgZ2hO3nE3PWj01zNskGcsks5uSROOgaJpZM4WCDEx> .

[jdubois]

I totally agree with the stack proposed by @deepu105 - that way it is pretty close to what we already have with Angular and React, and we can hope to have some common code here. Besides, it's very important for our users, as they will be able to move from one stack to the other: that's one of our big selling points on the server side (for example, MongoDB and MySQL look really similar, so people can shift from one project to another easily), so I'd love to have the same on the client side.

In order to help you here, I would like to open $500 in bug bounties in September -> if you can create 5 "feature requests" from the stack here, I will give them the $100 label next month.

[deepu105]

@jdubois thats a good idea. I'll create tickets and assign the label for the important parts at the beginning of September. Is that ok?

[jdubois]

Yes please do.

[deepu105]

closing as its decided