[Survey] Why you're not using vbuild?

[egoist]

If you can't find a proper reason in the poll, please reply in this issue.

Poll: http://qstn.co/q/AP3UZqzO

[Anonyfox]

In short: eagerly waiting for 3 things:

• SSR: compile a server-bundle.js ready-to-use for our express.js server without much hassle
• unit testing for components
• integration testing for complete vue.js apps

While we're using vbuild already for standalone components, we can switch to it only if it handles the above issues stupidly simple, or there is no real benefit of switching to it when we have to configure everything by ourselves afterwards.

But don't take this negative, I'm loving vbuild whenever I need to kickstart something fast, really. Please keep up the good work and kudos to you!

[egoist]

@Anonyfox thanks for the words, so:

• SSR, would you use Nuxt.js or how do you feel about it? If you only need to compile a server-bundle.js it would not be hard to achieve by updating webpack config in vbuild's config file.
• unit test: Do you have some desired solution for this? vbuild actually works with Karma already
• integration testing: it's in the plan

[Anonyfox]

we started with vue 1.X in our project in mid/late 2016, with the webpack settings of the time, gradually increased the versions of vue/vuex to the most recent ones (2.X) over the last weeks, but no one really wants to tackle the neccessary webpack changes. I started to introduce vbuild for developing standalone components for the main app several weeks ago (where this project seems like it won't receive much updates) and I'm still surprised now that I see this amount of recent activity. Again: Kudos!

Basically I would love to throw away all the "old" webpack mess and endless package.json stuff in not-so-recent versions in our main project, and let vbuild handle all the details. SSR is just something we're currently not able to do (because old webpack'n'stuff). We just replaced the deprecated vue-resource with a universal-fetch package, so in theory most stuff might work now for SSR.

I really don't care for the absolute latest and greatest bleeding edge versions of everything, but completely hiding all the horrible micro-configuration stuff would help with very notable productivity slow-downs for our small development team.

A note on testing: I just saw that there seems to be testing in vbuild at all. Last time I checked the "book"/tutorial there just was a big "TODO". :)

Oh and please: do NOT go the route of real server assumptions. compiling a hassle-free server-bundle.js (or maybe something even simpler that I can just require and drop into express.js?) would be golden! Let the gazillion of backend dev's and their tools take care of the rest, there are just too many opinions out there if you want to please backend folks, too! (but this is just my opinion as a full-stack dev)

EDIT: what I mean is that we for example already have a huge API-and-more express.js app, which could just run the frontend via SSR in addition to (currently) just serving the assets as files. No need or desire for using a full framework like nuxt for this, just executing a server-bundle.js is what we want. Other people might already use other frameworks (koa, sails, ...) and also would love to just have a compiled JS file they can plug into their existing stack. And if I would want to go extreme fullstack/universal, there already is Meteor with unmatched prototyping productivity (trading of scalability, but still). Does this sound helpful to you?

[egoist]

Great, completely hiding all the horrible micro-configuration stuff is what vbuild is trying to achieve 🤗

[egoist]

Published vbuild-karma to make it easier to run unit tests with vbuild

[codeofsumit]

still have it in some projects but I stopped using it as vue-cli has all the features I need now, it's official and I had less problems during setup or usage. I know that last bit is vague but it's my experience (had around 15 projects with vue. After 4 (I think) I switched to vue-cli)).

[egoist]

@codeofsumit do you mean the vue-cli webpack template?

[codeofsumit]

yes. It's enough even for our biggest projects right now.

Small example just because it's happening while writing this: Just opened a project (about 2 months old) that was created with vbuild 4.x.x. The build now suddenly fails for some reason (dev works fine). I updated vbuild, now everything fails. I know this is likely my fault but "doesn't work and I don't know why" happened to me much more often with vbuild than wie vue-cli webpack. Nonetheless as I wrote in other issues here: vbuild is pretty awesome.

[egoist]

@codeofsumit can't blame you, there're many breaking changes (as expected, v4 to v6)

I'm trying to keep it more stable though, should be been quite better now.

[sylvainpolletvillard]

I just started to give vbuild a try,

My first impressions:

• not sure if is better than vue-cli/vue-loader and why
• not sure if .vue files were supported. I searched for .vue and single file in the README and found nothing. Then I finally found a reference to them in the Babel section. The hyphen tricked me here. Also, I looked at the website 3 times before noticing the import from "Counter.vue" in the first code example. The render function is much more visible (maybe because of syntax coloring) and made me think it was not the example I was looking for. I think you should make a clear statement in the first sections of the README telling that .vue files are supported.
• speaking about the website, although it is very elegant, I found it not useful at all. Lots of scrolling for very few information, links are not easily accessible, and I just figured it out that code examples and demos are not static images. Also who is this girl staring at me and what does it have to do with the project ? Honestly I would have preferred a ugly website with more content and docs. But you can do both: minimalistic slick design and rich content ; vuejs.org is the perfect example.
• I'm a bit concerned about the sustainability of one-man projects. But Vue was also a one-man project at first and I do myself only one-man projects for open-source. Anyway, a few words about who you are, what is your background and what are your intentions over the long term for this project could help reassure people.

• I struggled with setting up the "Hello world" example, which is quite rare for me and kinda upset me. Here is what I tried: I guess these are novice mistakes but it really surprised me to get a blank page without errors on such a simple example. I thought it was related to my directories and tried many things before figuring out that returning a string as a static template is not possible and you have to use JSX notation with an explicit h argument

  I'll let you know how I feel with it in a few days.

[egoist]

@sylvainpolletvillard Thanks for the feedback!

not sure if is better than vue-cli/vue-loader and why

vbuild includes vue-loader by default, comparing to using vue-cli's webpack template, your project only needs one dev dependency and fewer configurations.

not sure if .vue files were supported

I thought it was obvious, maybe I should explicitly point this out somewhere.

speaking about the website

the website is really for demonstrating for now, do you prefer a website over the readme?

---

For your screenshot:

1. this is JSX so no need to use backquote here
2. no error because Vue won't render it if the return value is not a vnode
3. h is required if you're using JSX, if you came from React, you know you need to import React from 'react' to use JSX. since the JSX will be compiled to h() function here. You can learn about it here: https://github.com/vuejs/babel-plugin-transform-vue-jsx We use JSX in the root component because it does not require a runtime which is needed when you use template option and it's more straight-forward than using h() function directly. See also https://vuejs.org/v2/guide/render-function.html#JSX

You can see the JSX compiled result in the live editor: vue-jsx.surge.sh

[sylvainpolletvillard]

vbuild includes vue-loader by default

Oh, I did not know that ! This is also very important information, why is there no reference at all to vue-loader in the website and readme ? Don't assume these things are obvious, maybe they are for you but not for newcomers. We shouldn't have to dig in vbuild source code to get this information.

do you prefer a website over the readme?

Both are important in my opinion. Having a documentation website often helps for searchability though.

h is required if you're using JSX

I think it is a caveat of babel-plugin-transform-vue-jsx. It assumes that a variable h is declared in the scope instead of using existing parameter name or automatically add it when not defined.

This is very confusing for newcomers in my opinion, since ESLint and my IDE complain when I declare unused parameters. Maybe I will open an issue on babel-plugin-transform-vue-jsx to discuss this point.

[egoist]

@sylvainpolletvillard

We shouldn't have to dig in vbuild source code to get this information

So it's time to improve it now :D

btw, for the JSX question, that's really related to Vue itself.

[egoist]

@sylvainpolletvillard

and one of the use cases is, you can prototype really fast, no need to download template, perfectly suits your existing project. For example, I just made a stupid library hanabi and used vbuild to setup an example in under a minute

[egoist]

@Anonyfox I just revisited the nuxt.js project, seems you can use it as a middleware to work with any server framework like koa seamlessly.

[egoist]

@sylvainpolletvillard FYI, in babel-plugin-transform-vue-jsx@3.4.0, there's h auto injection support

[sylvainpolletvillard]

@egoist: and there is a nice article about this change : https://medium.com/@nycudr/a-small-change-with-big-consequences-or-why-did-i-start-open-source-d6616acd7df1#.b18arn3xx

[franciscolourenco]

Its not clear in the readme the features which are supported. Maybe add it in the style of vuepack readme?

[franciscolourenco]

Does vbuild support offline mode like vue-pack?

[egoist]

@aristidesfl for any webpack project you can use offline-plugin to make it offline-ready, here's an example project I made which uses vbuild and offline-plugin: https://github.com/egoist/codepan

And here's the doc about this: https://vbuild.js.org/#/recipes/progressive-web-app You can ignore manifest.json if you only want the offline feature.

[franciscolourenco]

Thanks, I was looking into a template like vuepack, with offline enabled by default, but which uses vbuild.

Second question: How does vbuild compare to vue-cli-build. Are you responsible for both? Which one to use?

[egoist]

@aristidesfl you may get the answers here https://github.com/egoist/vbuild#faq

// P.S. one of the reasons that people might use vbuild is they don't need to look for a boilerplate 😂

[franciscolourenco]

Hm have you thought about merging vbuild into vue-cli build?

[franciscolourenco]

The confusion with vue-cli build was that you are using it this template https://github.com/egoist/template-vue/blob/cb38f95d26baf3c7019704ac189a9b0765846362/template/package.json

[abelovic]

@egoist - I like this project!

I was originally looking to use nuxt.js but I ran into one major issue - their current lack of server less support (which is how I found your project). Before I switched to Vue from React I was following the Next.js project. After I started using these frameworks it is pretty hard to go back to boilerplates. Boilerplates have their purpose and are nice when you are either a) learning or b) doing the same type of project over and over again. The problem is when you start to build production apps you are no longer playing with technology and there are always changes over time making the code hard to maintain. The ability to update vbuild to the latest version with npm and not have to worry about the inner working of webpack while getting the most common features (that everyone uses) is HUGE imo

Having said that (as others mentioned) the documentation needs more work. For example when I couldn't find what I needed in the docs I naturally searched the issues list. All the examples for aliasing were using mergeConfig. When I tried this in my code I couldn't understand why it wasn't working? ...until I realized later you deprecated it in v6 duh lol Better documentation helps alleviate much of this kind of wasted effort

One thing I would also like to see you explore is to provide the ability for us to update versions of core pieces like vue. I know this was discussed in the next.js project at one point as well (although I am not sure if they solved it). Right now you seem very attentive to this project but over time this may not be the case (the vue-material project for example has PRs piling up for almost 2 months now with only 1 maintainer). If critical core dependencies are released that we need, we are stuck until you update your package ;) Not sure how hard this would be to do but I think that would be a pretty beneficial feature (use at our own risk of course).

Just my 2 cents... as I said I am using this to build a prod app currently and it has been really helpful to me! Thanks for your hard work :)

[egoist]

@abelovic you can install desired vue and vue-template-compiler version in your project

[egoist]

Planning to improve unit test experience, currently this would work though

[dodas]

// P.S. one of the reasons that people might use vbuild is they don't need to look for a boilerplate 😂

but I still need to create basic directory structure and files like index.js, right? Is there any template I can use which would generate basic structure for me? With POI as a dev-dependency maybe?

thanks

[egoist]

@dodas

You don't need to care about build configs means you can start from a index.js and progressively add new files when you actually need them.

And the folder structure doesn't really matter, maybe using something like this (the official Vue webpack template src folder):

or any type of structure you like

[egoist]

@dodas here's a simple template, it doesn't do too much tho https://github.com/egoist/template-vue

[Rayraegah]

I started using poi today. My experience with create-react-app wasn't good and I'm skeptical about build systems since. To date Brunch has been the only build tool I've trusted.

So what made me choose poi for my vuejs project? Long time use of Vuepack. I was about to vue init it again and noticed a link on the read me that said vBuild and I ended up using poi.

[egoist]

@Rayraegah I haven't tried Brunch but it seems like a simplified version of Gulp.

So can you share your experience with create-react-app (why it's not good enough for you)?

Poi is similar to react-scripts in create-react-app, so basically it has the same benefits as create-react-app but Poi is configurable.

[Rayraegah]

@egoist I couldn't configure my build without ejecting the react-scripts. (this was back in 2016 btw).

Example: sometimes, I wanted to set up a babel-plugin-import say for ant-design components or use prettier to format certain files... there was no way to override the build config without ejecting the scripts.

https://github.com/facebookincubator/create-react-app/pull/1103

[egoist]

@Rayraegah Hmm I think we don't have that problem in Poi, since you can even modify webpack config and babel config is fully supported. However we don't support eject 😅

[egoist]

Closing this since things have changed a lot in Poi (Previously vbuild).