Closed digitalextremist closed 1 month ago
Hey there.
Which version of the Vite bundler are you using? Currently the most up-to-date version of the library is available through the fork. I believe we shipped some changes a few months back to address custom Vite host configs.
https://github.com/JorgenVatle/meteor-vite
Try the latest versions of meteor-vite
and jorgenvatle:vite-bundler
.
Thank you @JorgenVatle it does seem the host now changes with the upgraded packages.
Still seeing http
hard-coded though. And noticing your vite-bundler
fork is not taking 2.0
of your package until meteor@3
so started upgrading to v3
now. Now that I see it is likely a version issue, I will dig further.
Parting question: Is the appropriate place to affect what baseUrl
is being used server.hmr
in vite.config.js
?
Much appreciated for unblocking me on this enough to go further.
[ I did try moving to http
for local development, but this first application requires video/microphone, so it requires https
]
Oh, could you point me to where you see the hardcoded http
protocol?
The package versioning is a little confusing. jorgenvatle:vite-bundler@1.x.x
is for Meteor v2, whereas jorgenvatle:vite-bundler@2.x.x
is for Meteor v3. The package should be more or less the same for either Meteor version. We're just forced to publish the package using an environment where Meteor v2 or v3 is installed depending on which version we intend to publish. Depending on the environment Meteor ends up including packages it shouldn't in the final bundle, in turn breaking the released package. The source code for the vite-bundler package is still the same. In other words, you're fine to stick with v1. 😄
I did try to launch an app with the following Vite server options, it did attempt to load the Vite client over https. But it was naturally rejected because of the missing certificate. (jorgenvatle:vite-bundler@2,0.0
and meteor-vite@1.10.3
)
// vite.config.ts
export default defineConfig({
server: {
host: 'localhost',
https: true,
},
plugins: [...]
})
Your baseUrl
will be affected by the server.host
field in your Vite config, like in the snippet above. So if you change host: 'localhost'
to 0.0.0.0
or true
, it should be accessible from your local network.
Just set up a branch with React and Blaze: https://github.com/JorgenVatle/meteor-vite/tree/react-blaze/examples/react
Thank you @JorgenVatle! That was the last piece: server.https: true
does change the URL now, with the latest version. I appreciate the caveat about v2
of meteor
being just fine ( which is great, since v3
seems to brick on update right now )
Quite right on the SSL failures next. The intent is to use locally-issued LAN minica
certificates and nginx
even in development, but at several local terminals. I can see from here ( and with the example you added ) that I am almost into open water now, after I fix up ports and certificates, now that I can toggle https
in this version!
It seems any host I provide ( rather than an IP address ) changes back to localhost
for some reason, but I can work with a naked IP address as long as it is a LAN versus local-loop address. So for now, so far so good.
For the record, I used the Vue
started baked into meteor
but it seems that is out of date. I am grateful for the intervention! Honored to be entering a community of people like yourself. I look forward to doing some heavy lifting within the ecosystem!
Have a great time out there //
By the way, this is what I referred to, that "changes back to localhost
" above:
let baseUrl = config.resolvedUrls?.network?.[0] || config.resolvedUrls?.local?.[0] || `http://localhost:${config.port}`;
I see. Thanks for following up on this. 🙌
This should prioritize the configuration provided by Vite. Falling back to localhost if nothing else is available. Are we hitting the wrong resolved URL index in your use case?
If memory serves right, this was an issue with earlier versions from late last year where we would assume Vite was only being used on localhost
only. There hasn't been any issues since upgrading, has there? 👀
For a moment I bypassed the situation and went toward the production
side to make sure it deploys ( LAN first, cloud later ) and that does. Everything works without HMR
. So now I am coming back to the development
case.
What I see happening is that if I use a FQDN in the LAN, with an address set in /etc/hosts
on each machine, is that the URL gets rendered as with an IP address. So if server.hmr = 'host.lan'
then in the rendered html it will be https://lan.ip.address.number:port
because it will be config.resolvedUrls[.network[0]
as pulled by host.lan
resolving to lan.ipaddress.number
... What I want to be able to do is remove the :port
portion and set the output to:
<script src="https://host.lan/@vite/client" type="module" id="meteor-vite-client"></script>
<script src="https://host.lan/imports/ui/main.js" type="module" id="meteor-vite-entrypoint-script"></script>
And actually, now it does work, but without need to run a reverse proxy in the LAN for HMR. And there was one "gotcha" hidden in there. First the "gotcha" which was the key:
If running that command ordered, it breaks. Then if you do meteor npm upgrade
and rerun, meteor-vite@1.10.4
is added back, and it works again, but then the error above in the screenshot comes back up, requesting the regression.
Also it seems like there is a "gotcha" when changing vite.config.js
itself since that will change the URL also, but upon restart of the server it goes back to the LAN accessible URL.
Once through that and ignoring the official admonition to devolve, my problem was a misunderstanding of what was going on.
At the vite.config.js
level, the port needs to be set to the same thing both for server.port
and for server.hmr.clientPort
and then it works. It did not strike me properly at first that the meteor
server is itself, and then there is this separate vite
server, which server.port
is referring to, not to meteor
which is behind the reverse proxy on another port. Muddy water, as well as issue forming the script
links, as well as the package regression, all together and each individually broke what I expected.
There is no need to make HMR
more accessible than that, since everything on the LAN ought to be able to hit that... and I just checked and it works at three stations... though it shows as insecure due to the HMR certificate ( even though I generated one by minica
tied to the IP address which is technically not a hostname.
First of all @Akryum, thank you. What a service to both
Vue
andMeteor
you have provided. Thank you!Any chance we can change these values?
This gets set here:
https://github.com/Akryum/meteor-vite/blob/d189295c1f29f723742b7f16069f656fe43496e1/packages/vite-bundler/loading/vite-connection-handler.ts#L60-L61
Which is set here:
https://github.com/Akryum/meteor-vite/blob/d189295c1f29f723742b7f16069f656fe43496e1/packages/vite-bundler/loading/vite-connection-handler.ts#L51-L55
Which seems to pull
config
with typeRuntimeConfig
as an argument at constructor ofViteDevScripts
here:https://github.com/Akryum/meteor-vite/blob/d189295c1f29f723742b7f16069f656fe43496e1/packages/vite-bundler/client.ts#L34-L41
But then that is as far as I can trace it so far.
host
insettings.json
and using that;vite.config.js
various places but am stabbing in the dark a bit;server.hmr
tofalse
and also tried settingserver.hmr.overlay
tofalse
absoluteUrl
but was just wishing at that point;Also I noticed that the scheme seems hard-coded which causes warnings, but is not "breaking it" at all.
Goal is to be able to connect from another machine on the LAN, using
nginx
and/etc/hosts
entry. Everything on that end works, and is a common thing on this LAN, but then it hits thathttp://localhost:XXXX
call, and dies right there.Thanks for any nudge in the right direction possible, and pardon if there is somewhere better to put this.