Status of Vue 3 + Meteor?

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 :smiley:

Hi all,

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?

i18n is done at runtime and doesn’t have anything to do with Meteor specifically so you should be able to use any i18n lib/framework as usual

Ah thank you, I will have a look at i18n and try it out in a demo project.

1 Like

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?

Naïve question from a noob scratching his head.

Hi @jrobin
I’m taking a look at meteor-client-bundler and I’ll try to understand it a bit more. I’ll bring the discussion to our core team.

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.

Would it work with the Swydo/ddp-apollo package?

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.

If we could swap Isobuild for Vite, it would solve a lot of things.

1 Like

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.

Maybe it’s a better time now @akryum? :slight_smile:

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…

1 Like

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.

I backed @akryum already a time ago every month. When needed i do more. Vue 3 with meteor is quite essential for us. We have really an issue when the structure really changes and feel a bit abandoned. Would be good @filipenevola brings here also some clarity about the strategy of Meteor Company. I think a good integration of Meteor and Vue 3 is a must for the future.

He’s no longer associated with Meteor. But someone from Meteor, preferably @fredmaiaarantes could give us this clarity.

It’s not only replacing Babel/Webpack with Vite.

Zodern’s words:

Vite is its own bundler, and uses two others (rollup and esbuild), none of which would be flexible enough to bring over the parts of Meteor’s build system. For a very minor example, Meteor’s HMR system is designed to work better with break points set in older versions of modules, while vite’s has more problems that are impossible to fix without extensively changing how it works in development. Even webpack, which is much more flexible, isn’t flexible enough.

Vue integration packages have always been maintained by the community.

We need someone with experience (in Meteor and Vue) and willingness to work on it. As most of you know, @akryum has maintained these packages and we would love to sponsor him to keep doing this great work.

If he is not available, we need to find someone else. Unfortunately, we don’t have the time and expertise inside the core team. So your help is greatly appreciated in referring us to someone we could sponsor. As I mentioned before, Vue and Meteor are a great combo, and this integration is very important to us.


I think akryum has done a good job with the Vue 2 integration package. The package has been maintained and stable. Regarding Vue 3, as far as I can see, things have not moved quite as quickly as they might have. But akryum has created the base Vue 3 package and it is available for use (though not sure about any limitations, other than specifically needing Composition API instead of Options API). If the Meteor team and community members can motivate akryum to continue his work with some financial support, then that would probably be the best option. He’s a Vue core team member and, more importantly, has proven that he’s able and willing to maintain important packages not just during the initial excitement period of creating a new package, but also for the (much more dull) long term. And for commercial projects such stability is very important.

A few years ago another member of the Meteor community took it upon himself to (I hope I am recalling correctly here) create a Vue 3 integration for Meteor instead of akryum. That did not work out very well, as often happens in open source, and probably took some wind out of akryum’s sails as well.

In any case, I am very much interested in Vue and Meteor getting along well in the future. As my main projects relies on that. So very good to see the Meteor team showing interest in having the integration in good state!


we would love to sponsor him to keep doing this great work.

Hi @fredmaiaarantes, there are some PRs in vue-meteor repository that I think are very important to merge. One of them is this one. So, I wonder if you could start to sponsor him in order to animate him to attend the current PRs in the Vue 2 Integration?

As far as I know, we’re only 2 meteor devs who support him by sponsorship, they are:

(if you are not on the list, please mention it)

So, I think we need the support of the Meteor team to sponsor him, regardless if @akryum start to maintain the meteor-vue repositories again since he deserves support for his previous work.

1 Like

You are one of 78 sponsoring Akryum!