It is a full rewrite with TypeScript, Composition (and Options) API support. The Options API is very similar to the Vue 2 version (minus some removed APIs such as $startMeteor/$stopMeteor).
Together with vite:bundler, support of Vue 3 is nearly complete.
It is a full rewrite with TypeScript, Composition (and Options) API support. The Options API is very similar to the Vue 2 version (minus some removed APIs such as $startMeteor/$stopMeteor).
My dream has come true!! . I will be upgrading my apps (along with Vuetify 3 Beta) and I will share any feedback about the update . Thank you very much for this support!
I believe one can already write a meteor app with Vue 3 unless you need SSR (which isn’t supported by vite:bundler yet). It’s mostly a matter of finding bugs and fixing them now.
Are you using the Vite integration or the integration from the repo you created the issue? The recommendation is to follow the example below created by @akryum.
My app includes the new version of Vuetify along with other libraries such as:
Vue Router
Vuex
Vee Validate
Vue Draggable
Vue transitions
Sass
So, I think it is a very good app example to test the Vite bundler. In case anyone want to try it, you can do it in this branch Feat: Update to Vue 3 by diavrank · Pull Request #5 · diavrank/theory-swe · GitHub . I am waiting for Vuetify 3.1 to include the v-data-table (since I had to change that component for v-table by the moment) and then I will merge it.
I was debugging with a simpler app (the one which comes as example from the repo) and it seems that error happen when I import Accounts package in a vue component, as shown:
import { Accounts } from 'meteor/accounts-base';
However, I can still use the package in the client side (since it is a global variable) but it provokes this typescript error:
This is necessary to use functions from the client side such as:
Profile.ts is the file which contains the Profile collection to do find queries in the client side, like:
return ProfileCollection.find({}).fetch();
I am using Astronomy as ODM for my data layer, and it seems that Vite is complaining as well. In this case, I cannot remove that import statement because it is needed to create the profile collection as shown:
So, in this way, I can use the ProfileCollection in the client side to do find queries (when a subscription is made), while I have the model only available in the server side. I think that could help in the security scope (to avoid exposing the collection structure to the client side), but I’d like to know if that was the purpose by Vite? or should it support it? cc: @akryum
By the moment, I could already visualize something in my app
My app is practically migrated and working correctly ! It is just missing to fix some minor parts of design (due to the migration to Vuetify 3). I have just one question related to my unit tests. When I run meteor test, it is throwing this error:
W20221120-07:00:13.029(0)? (STDERR) internal/process/esm_loader.js:74
W20221120-07:00:13.051(0)? (STDERR) internalBinding('errors').triggerUncaughtException(
W20221120-07:00:13.052(0)? (STDERR) ^
W20221120-07:00:13.053(0)? (STDERR)
W20221120-07:00:13.054(0)? (STDERR) Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'vite' imported from /tmp/meteor-test-run3218uq.h76io/.meteor/local/build/programs/server/assets/packages/vite_bundler/worker-dev.mjs
W20221120-07:00:13.055(0)? (STDERR) at new NodeError (internal/errors.js:322:7)
W20221120-07:00:13.055(0)? (STDERR) at packageResolve (internal/modules/esm/resolve.js:732:9)
W20221120-07:00:13.056(0)? (STDERR) at moduleResolve (internal/modules/esm/resolve.js:773:18)
W20221120-07:00:13.056(0)? (STDERR) at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:887:11)
W20221120-07:00:13.057(0)? (STDERR) at Loader.resolve (internal/modules/esm/loader.js:89:40)
W20221120-07:00:13.058(0)? (STDERR) at Loader.getModuleJob (internal/modules/esm/loader.js:242:28)
W20221120-07:00:13.058(0)? (STDERR) at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:76:40)
W20221120-07:00:13.059(0)? (STDERR) at link (internal/modules/esm/module_job.js:75:36) {
W20221120-07:00:13.060(0)? (STDERR) code: 'ERR_MODULE_NOT_FOUND'
W20221120-07:00:13.060(0)? (STDERR) }
I could deploy my app by doing the build in my computer and then, upload the bundle to the VM to use it in a custom docker image to run the app:
bundle.dockerfile
FROM node:14.20.1
COPY theory-swe.tar.gz /opt/
WORKDIR /opt
RUN tar -xzf theory-swe.tar.gz && cd bundle/programs/server && npm install && npm run install
WORKDIR /opt/bundle
ENV PORT 3000
EXPOSE 3000
RUN echo 'Starting app...'
CMD ["node", "main.js"]
I separated the model and the collection in different files, leaving the collection in the client side and the model in the server side. Here is the solution.