Vugel support for Vite

[husayt]

This looks really interesting and works great, but only webpack is supported via vue-loader. It would be great if it could work with Vite.

Thanks

[RobbinBaauw]

Hm, to use Vugel you need to use a custom compiler, so it would depend on being able to register a custom compiler for Vite.

Another option would be using it like this: https://codepen.io/basvanmeurs/pen/vYNGRGP?editors=1010 (so with a custom render function)

Edit: note that the compiler="vugel" attribute is provided by a fork of vue-loader.

[husayt]

Thanks @RobbinBaauw I have also created an issue on Vite side.

May I ask, if compiler=xxx syntax currently supported or is this something unofficial? I know of custom block support in both Vite and Vue-loader, but couldn't find any reference to custom compiler support.

[RobbinBaauw]

This is added in the following PR: vuejs/vue-loader#1645

Didn't know of custom blocks, am trying to figure out a way to make it possible that way! I'm almost there

Edit: here's the repo: https://github.com/RobbinBaauw/CustomCompilerBlock. I think the only thing that is in the way is the fact that Vue is not available globally and when using the render function as module (https://github.com/RobbinBaauw/CustomCompilerBlock/blob/master/src/index.ts#L25), you get these imports:

import { createVNode as _createVNode, openBlock as _openBlock, createBlock as _createBlock } from "vue"

This gives the following error: `
Uncaught TypeError: Failed to resolve module specifier "vue". Relative references must start with either "/", "./", or "../".

Edit 2: Btw, an important part of getting this to work in Vite is having proper support for ESM. Adding that to Vugel and its dependencies as well.

[RobbinBaauw]

Added ESM support :)

[husayt]

@RobbinBaauw great stuff. Now when you made it work with Vite via custom block is this better than original <template compiler=xxx approach? It seems that this is closer to existing standards and hence we can get away without adding additional vue/vite level constructs.

[RobbinBaauw]

I don't think so. The way I implemented this custom block (for now only for Vite but it should be doable similarly for vue-loader) is by overwriting the render function. I think this is quite a hack, if you for example add a <template> block this will fail (as Vue overwrites it back). A much better way would be to override the compiler of the component, but this is not possible with custom blocks because you can only emit code, which means that you can't pass references to such compiler.

Another issue is a bit less fundamental: I had some ESM problems with Vue (same as in my last comment), so I made it a hardcoded path. I don't have the time nor enough knowledge on ESM to improve this currently. Any ideas?

To conclude: for development with Vite this should be plenty, but when actually putting an app in production I wouldn't really want to use this, hence I hope the vue-loader thing is going to get merged and a similar setting for Vite might be better too.

[RobbinBaauw]

Something like this could also work: RobbinBaauw/vite@9f76f26

[husayt]

@RobbinBaauw this is really cool stuff. Will be good to discuss both these approaches on Vite repository and probably worth to proceed with pull request to get more feedback.

[husayt]

@RobbinBaauw Seems like we have a green light now. Support for custom compiler options have just been added to vite and it's rollup plugin. Here it is.

[RobbinBaauw]

Great! Then we have vuejs/rollup-plugin-vue#368, vuejs/vue-loader#1645 and vitejs/vite#488

[RobbinBaauw]

Closing, feel free to reopen if you have any more questions.

[husayt]

@RobbinBaauw will be probably also great to get the example you had reimplemented with new way provided by latest vite change, to make sure all holds together and nothing was missed. I have used that example yesterday to put some basic demo together, but was stuck with broken v-for. Hopefully, with this there will not be such issues.

i have to say, this is all really amazing stuff. I was overjoyed when managed to get vugel working in my simple vue-vite demo yesterday. To have both DOM/Canvas/WebGL updates controlled by Vue reactivity this opens huge amount of new possibilities. Once this becomes stable I am sure there will be plenty of applications using this. Currently to make canvas changes in Vue application is like taking cold shower, you have to leave comfort of data binding provided by vue and do things old way. This will allow for the same DSL used for DOM by Vue to be used also for Canvas/WebGl. Really shows power of Vue3 and also have to say Tree2D/Vugel seems to be very fast. Kudos to everyone who made this possible @RobbinBaauw, @basvanmeurs, @yyx990803, @underfin and everyone else.

[RobbinBaauw]

I think we can convert our example repository to Vite once vitejs/vite#488 gets merged. You can see our current webpack config there as well.

It is indeed very fast, we are using it internally to build a new product (which is where most of the testing of Vugel will come from, as we don't have a test suite on this repo) and we have been surprised as to what is possible. We might be able to publish part of this product as a showcase of Vugel in the future.

[Valian]

Hi guys! I'm working on making a Pixi.js renderer for Vue. Since it's very convenient to have HTML + canvas rendered within one app, it should work with HTML elements.

These PRs you listed seem very helpful, just they're not merged for a very long time. Is there anything moving on there? @RobbinBaauw do you know anything about compiler=X support, or it still has to be used through the fork?

[RobbinBaauw]

It seems that you'll have to write your own plugin for Vite: https://github.com/vitejs/vite/tree/main/packages/plugin-vue#options

[Valian]

Thanks, will check it out 👍