Cannot change "localhost" to LAN accessible hostname? With https?

[digitalextremist]

First of all @Akryum, thank you. What a service to both Vue and Meteor 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 type RuntimeConfig as an argument at constructor of ViteDevScripts 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.

• Have tried setting host in settings.json and using that;
• Have tried adding it to vite.config.js various places but am stabbing in the dark a bit;
  • Have set server.hmr to false and also tried setting server.hmr.overlay to false
• Have tried trying to set 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 that http://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.

[JorgenVatle]

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.

[digitalextremist]

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 ]

[JorgenVatle]

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.

[JorgenVatle]

Just set up a branch with React and Blaze: https://github.com/JorgenVatle/meteor-vite/tree/react-blaze/examples/react

[digitalextremist]

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 //

[digitalextremist]

By the way, this is what I referred to, that "changes back to localhost" above:

https://github.com/JorgenVatle/meteor-vite/blob/abbd0d67d908c6d527f0bb978306ddda125a5aa1/packages/vite-bundler/loading/vite-connection-handler.ts#L98

let baseUrl = config.resolvedUrls?.network?.[0] || config.resolvedUrls?.local?.[0] || `http://localhost:${config.port}`;

[JorgenVatle]

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? 👀

[digitalextremist]

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>

[digitalextremist]

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.