@denyhs created an example project using Vue 3 + Meteor + Tailwind and it is working fine. You can take a look at the repository.
There is this open discussion where some issues were mentioned and also fixed by @satyavh.
Robert (Bob) is connecting me to @akryum to check if he can continue to maintain the integration we have. And it would also be great to have more Vue developers involved.
Hi, thanks for give attention to the Vue integration. I think one of the features most wanted is having the support of the current Vue 2 + Meteor syntax is key to allow smooth migration. Once that done, I could update my scaffold app about Meteor + Vue and then provide feedback if that integration is complete (at least for my projects).
Because I’m also using Vue 2 + Meteor right now, I’m looking for support of the Vue 3 Options API (which is the same as the Vue 2 component style we all originally chose Vue for)
We did have some contact with @akryum via email this week, so adding the Vue 3 Options API seems to be the biggest requested addition.
@akryum provided us with the following starting to-do list:
Hey! About the Meteor + Vue 3 integration:
1- Currently the big missing feature is being able to use other languages inside .vue files, such as TypeScript, SASS, Stylus, Less…
AFAIK Meteor doesn’t support ‘passing’ content to the build toolchain like Webpack or Vite/Rollup. In the Vue 2 is was done through putting stuff on global and writting building code for each language. Is there anything that Meteor could provide to help achieving this?
2- It’s missing a Vue Option API version (currently only supports Vue Composition API).
3- (Not very important) Meteor HMR system doesn’t support HMR requests for parts of a module (for example just the .vue file template).
Regards,
Guillaume
For me, I’d also like some ongoing support for Vue 2 as long as possible until we have the time or resources to work on a Vue 3 upgrade. So I’d also like this thread to help cover what we need for ongoing Vue 2 support if there are any bugs in current projects or issues with Vue 2 as we all upgrade Meteor.
We just need to support a clear and easy path for all the Vue 2 projects to eventually make the upgrade to Vue 3 and if we can write an easy basic guide along the way for everyone, that would be great too.
Hi, this is very much appreciated.
As a noob it would be great to have a project create CLI option with the choice --vue2 and default --vue to be the Vue3 version as Vue3 is now the default Vue version.
Vue3 + Tailwind is an amazing combo which especially newcomers will like, I would guess.
Not my intention to hijack the post, but I see @mullojo has touched this point as well. I was wondering if any of the PRs will be addressed for the existing vue-meteor package (Vue 2 support). See Pull requests · meteor-vue/vue-meteor · GitHub
I know @akryum is extremely busy and has a lot on his plate all the time. But as pointed out, some of our projects depend on Vue 2 + Meteor and I didn’t have much luck trying to update Meteor in an existing one, for instance.
Thanks for all the hard work and very pleased to see the willingness to keep Vue a part of the Meteor ecosystem
Is i18n support already available? I did see an example (GitHub) from @akryum but I guess that is Vue 2 as it is a project from 6 years ago. Or is i18n completely independent from Vue?
I keep wondering what are the unique benefits of the approach of using the meteor CLI extensions such those from the meteor-vue project to simultaneously build (a) the front-end with a front-end framework such as Vue, (b) the meteor back-end and (c) the reactivity between both ends, as compared to the alternative approach of using (a) the meteor CLI to build just the back-end, (b) using the front-end framework CLI (e.g., Vue-CLI, now Vite) to build the Vue front-end and (c) using Urigo et al’s meteor-client-bundler to build the reactivity between both ends?
Isn’t the meteor-client-bundler front-end agnostic and thus does not need to be extensively refactored everytime Vue (or React or Angular for that matter) changes version and CLI which seems to be the case with the meteor-vue approach and which almost guarantees that the integration will always be one or a few steps behind the evolution of Vue?
While it seems that the meteor-client-bundler has been abandoned since mid 2020, wouldn’t resuscitating it require less work than thoroughly refactoring the meteor-vue packages while also minimizing future work every time Vue changes version and CLI?
Since the Vue3-Apollo integration seems well maintained and documented and supporting GraphQL subscriptions, I thought that a third way to keep up the Vue-Meteor integration in versioning sync might be to use Apollo as middleware between Vue3 and Meteor2 rather than the Vue-Meteor packages or the Meteor Client Bundler.
Bringing in such a heavy dependancy as Apollo to Meteor projects just to sidestep issues with the vue-meteor integration package would definitely not be a good idea. Even if this would work now by enabling the use of the vue3-apollo package in Meteor projects (not really sure how), in the long term such hacks almost invariably cause more problems than they solve. And maintenance would become a nightmare as well.
The current Vue 2 integration core is less than 2k lines of code, if I recall correctly. vue-meteor-tracker around 500 LOC and akryum:vue-component around 1500 LOC. Not astronomical. The best way to make progress on the vue 3 integration package faster is to head over to Sponsor @Akryum on GitHub Sponsors · GitHub and commit a monthly contribution to him in whatever sum you deem fit. I think the Meteor team should do the same.
It seems like a good idea … if Akryum is lacking more funding than available bandwidth, that is. Given that he is also the maintainer of the Vue-Apollo integration and that he is sponsored by Evan You and other important skateholders in the Vue community, perhaps going the Vue-Meteor integration through the ddp-apollo route is not such a bad idea. Especially since it also could be used for any front-end for which an Apollo client is actively maintained.
From the Meteor team perspective, the best ROI would be still IMHO to invest in maintaining Urigo’s Meteor-Client-Bundler since by decoupling the build of the client from the build of the Meteor server, it seems to be a single package that lets you simultaneously maintain Meteor integration with the latest versions of all front-ends advertised as Meteor compatible on Meteor landing page: React, Angular and Vue, plus Svelte advertised on Meteor’s tutorials page.
We started a conversation some time ago, but it ended without any conclusion. That’s when I started this topic. I imagine @akryum had a lot on his plate at that point.
I’d love to see this integration progress, many members here use Vue + Meteor, and I think this is a powerful combo. Meteor Software can become your Gold sponsor @akryum, and I believe other community members would be happy to contribute as well.
About using Vite, it seems to me that this would be very difficult as Vite is its own bundler. @hschmaiske brought this question to @zodern and he has many reasons why this would be a difficult path to take.
Going the ddp-apollo route only will leave those of us with applications based on the Akryum’s Vue 2 Tracker without a way out. The need to migrate to Vuetify 3 will also put pressure on us since it requires Vue 3… Starting to get worried here…
Are there any other promising paths currently on the table to improve build times and local refresh speed? I recently helped switch a couple of React projects from Webpack/Babel to Vite, and the speed improvement has been immense. Unfortunately, Meteor now feels disappointingly slow by comparison.
