Open timsun28 opened 1 month ago
Hi,
I am using Meteor-vite (with Svelte frontend) and I experience the same behaviour as @timsun28
I have the same problem. For quite some time now, several months at least.
"meteor-vite": "1.10.4"
"vite": "^4.5.3"
jorgenvatle:vite-bundler@1.12.13
Just shipped a couple patch releases to address this. Try with meteor-vite@1.11.1
and jorgenvatle:vite-bundler@2.1.3
. Let me know how it goes 🤞
Thank you for shipping new updates! I've tried updating the packages, and updated the configuration so the server is now also bundled according to this changelog.
I've pushed my changes to this branch, but I've found that the methods aren't being loaded properly. This is both the case for regular methods and zodern relay.
Thank you for looking into it!
Ahah, happy to see that someone's keeping an eye at the changelogs. 😄
I wouldn't recommend enabling the server builds just yet. There's still some work left to be done before it's stable without additional configuration. zodern:relay
for example will not function with this enabled due to the way @zodern/babel-plugin-meteor-relay
relies on module import path matching for determining whether to transpile method and publication modules.
The serverEntry
option will bundle your server into a single module for Meteor, so the Babel plugin doesn't receive any valid paths to match against.
zodern:relay
still does work with Vite server builds, it just requires some additional Vite configuration to ensure the import paths aren't lost.
I'll have a closer look at that branch in a bit. 👍
Thank you for the quick reply!
I have tested with your branch (so without the server builds) and it is working as expected now!
Using meteor-vite@1.11.1
and jorgenvatle:vite-bundler@2.1.3
.
This issue can be closed if @martijnbar and @red-meadow also have the same findings.
meteor-vite@1.12.0
and @meteor-vite/plugin-zodern-relay@1.0.6
should resolve the issue you were seeing with the serverEntry
config option.
The server entry option now uses Vite's SSR build under the hood, so it should be safe to re-enable the option again. 👍
Try with
meteor-vite@1.11.1
andjorgenvatle:vite-bundler@2.1.3
. Let me know how it goes 🤞
@JorgenVatle , thank you for your quick reaction! Do I understand correctly that I should migrate to Meteor 3 in order to use jorgenvatle:vite-bundler@2.1.3
? With Meteor 2 I get Constraint is not satisfied...
errors.
I pushed the update with serverEntry and version 1.12.0 and 1.0.6 to the same branch I mentioned earlier.
I am still getting the same error as before, so I'm not sure where I'm doing something wrong. I had a look at your Vue + SSR example project and added the "enableExperimentalFeatures" flag in the vite config, but this didn't help.
A more general question, is this only an improvement for local development or is this also something that will help improve with deployments? And should the server/bundle folder be excluded from your git repo or is it something to add into it?
Thank you!
Try with
meteor-vite@1.11.1
andjorgenvatle:vite-bundler@2.1.3
. Let me know how it goes 🤞@JorgenVatle , thank you for your quick reaction! Do I understand correctly that I should migrate to Meteor 3 in order to use
jorgenvatle:vite-bundler@2.1.3
? With Meteor 2 I getConstraint is not satisfied...
errors.
Oh, the release branch for Meteor v2 (jorgenvatle:vite-bundler
v1) is a little bit behind the current v2 release, supports Meteor v3 only . The 3.0 pre-release branch for jorgenvatle:vite-bundler
supports both Meteor v2 and Meteor v3 and has all the latest changes if you're willing to upgrade.
https://github.com/JorgenVatle/meteor-vite/pull/173
meteor add jorgenvatle:vite-bundler@3.0.0-meteor2.next.21
npm i meteor-vite@next
@timsun28 The server entry feature should speed up build times when deploying for production and when Meteor needs to rebuild the server on file change in development. Another benefit is that you can rely only on Vite config for things like import aliases.
Though, in its current state, that doesn't appear to be the case. Since Vite will do a full app rebuild when server-side code changes, plugins can end up slowing down builds quite a lot depending on the work they need to do. In the v3 pre-release I have an alternative implementation for the server-side builds that uses ESBuild instead. This ended up quite drastically speeding up builds. But at the cost of limited integration with your Vite config. So zodern:relay
support is lost yet again. 😅
I'll have a look at the branch there in a bit and follow up with you.
@timsun28 Just pulled the latest from the branch in a fresh workspace and everything seems to work as it should. What OS are you on?
@timsun28 My mistake, turns out I didn't pull the latest changes. 😅
I've submitted a PR for you. The server mainModule
was pointed to some temporary files created by a previous version of meteor-vite
.
https://github.com/timsun28/reproduction-vite-server-reload/pull/7
Hi,
While I was using the vite plugin with my app I found that whenever I just changed a meteor method it would update in the terminal, but the client wouldn't update. When i tried to fetch data it would still have a reference to the old server data on the client and I would need to refresh the browser page to get it to work.
I recreated this issue in this repo. When you run
meteor run
it will show two buttons that will trigger a zodern method and a regular meteor method and alert() the response from the server.In the
/imports/methods/links.ts
there are two methods where in this scenario you would change the string and save the file. This will refresh the vite server[vite] hmr update /imports/ui/App.tsx, /imports/ui/Info.tsx
.But then when you click the button it will alert the old message. After you refresh the browser page and click the button again you will get the updated version.
This happens with both the zodern and regular methods so I can assume it's a more general issue.
Thank you and if I can help investigate this further let me know!