Endless reloading by start svelte-kit it with VS Code Remote-SSH terminal #1134
Comments
|
This is presumably the same thing as #844 in that an inability to access the websocket used for HMR is causing an endless reload. |
|
Opening port 24678 on the server and forwarding it in VSCode resolved the issue for me and enabled auto-reload. I use it with remote development with VSCode in Docker containers. You want to see something like this in the Chrome console: This error in the console says there is something wrong with the Vite connection: Some background informationSvelteKit uses Vite for its hot module reload (HMR) feature. This uses a WebSocket that uses a different port than the one opened with Sveltekit (default 24678, but it is configurable, but the configuration seems to not apply with SvelteKit). When you fire up SvelteKit using Related topics
|
|
I just want to inform that this is still happening on @sveltejs/[email protected] And opening port 24678 is working as a workaround |
|
this is still happening on |
|
@GreenRobot777 -- Are you opening up both your application port (default: 3000) and the websocket port (default 24678) on your remote server? This has been suggested as a "workaround" -- which really is a misstatement. It's absolutely necessary to manually open those ports, as the browser client (running on the local server) needs to connect to those ports to support HMR. SvelteKit can't alter your system's firewall settings. This necessity applies to Docker containers, too. You also need to specify For me, I changed svelte.config.js as described above, then executed commands 1 through 5 in your Reproduction instructions, then: If you just want to use the default ports, omit changing your svelte.config.js, and run: I hope I understood your issue correctly. Please let me know. If this does resolve your issue, |
|
I'm having this issue using WSL2 and Nginx as a reverse proxy with https and custom domain (http://localhost:3000 -> https://svltkt.local). Opening the ports and using |
|
@drejohnson Which SvelteKit version are you on? The above workaround was for http, however the latest version of SvelteKit has fixes for https. You probably want to upgrade. |
|
@JBusillo I'm on 1.0.0-next.114. Still doesn't work for custom domains ( |
|
next.114 does have the modified code. BTW, there was a next.115 just published less than an hour ago, but that shouldn't affect this. Do you want to go over this using Discord private messaging? Then we can post our resolutions back in this issue. My Discord id is "Joe Busillo#8928". |
|
working example of nginx vhost via wsl2 |
|
Just to mention: I had the same problem with a custom domain. As soon as I tried to invoke the application with a custom domain, it started reloading the page every 2-5 seconds. HMR-port was open as stated above, no ports were blocked by some firewall, it even happened when I started it locally with |
|
Still happening on 1.0.0-next.146 |
|
Still happens with 1.0.0-next.164, but a little different for me.
|
|
Specifying the forwarding ports in "forwardPorts": [3000, 24678], |
|
Not for me, HMR still doesn't work even with update to 1.0.0-next.164. None of these workarounds should be necessary, VSCode Dev Container detects and forwards all ports automatically, no setup needed:
And the manually opening ports solution suggested by @JBusillo also shouldn't be necessary exactally because this same reason. I'm working on a @vue/cli project running inside a VSCode Dev Container (Docker) inside WSL2 Alpine Linux on Windows 10. And the ports are automatically opened and forwarded, server and HMR work out of the box, no extra setup. But @sveltejs/kit can serve only the base application port but not the WS one for HMR. |
|
I think Here are my svelte config file and docker compose file. Again, this works with svelte.config.js docker-compose.yml |
I don't have this reload in I saw this document: https://github.com/sveltejs/svelte-hmr#noreload. Maybe it's a workaround, but I don't see how I could use this. |
I ran into it, and I got the same. I tested it as well. |
|
I made some tests on "@sveltejs/kit": "1.0.0-next.169/170"/ "@sveltejs/adapter-node": "1.0.0-next.49". // svelte.config.js
kit: {
adapter: node(),
target: '#svelte',
ssr: false,
hostHeader: 'X-Forwarded-Host',
vite: {
server: {
hmr: {
host: 'localhost',
protocol: 'ws',
port: 3001
}
}
....
}# docker-compose.yaml
frontend:
image: frontend-0.0.151
user: node
working_dir: /home/node/app
volumes:
- ./frontend:/home/node/app
command: npm run dev
ports:
- '3001:3001'
networks:
- frontendresponse for ws://localhost:3001/ using "@sveltejs/kit": "1.0.0-next.168"/ "@sveltejs/adapter-node": "1.0.0-next.48". It's working correctly. Response for ws://localhost:3001/ using "@sveltejs/kit": "1.0.0-next.170"/ "@sveltejs/adapter-node": "1.0.0-next.49". The browser reloading after this request. The browser always reload after it try to access ws://localhost:3001/ using svelte.kt 169 or 170. Using 168 it don't reload. My frontend container is behind haproxy with self sign certificate. Only the port 3001 is open for vite without certificate. I'm not accessing via SSH but via normal browser. What was changed in Vite/Svelte from 168 to 169 version? Thank you for the help. |
|
lol |
|
Today using And now it starts reloading endlessly again. I have a custom Edit: Removing the |
This didn't work for me. |
|
After many tests and configurations, this solved the endless reload: // "@sveltejs/adapter-node": "^1.0.0-next.51",
// "@sveltejs/kit": "^1.0.0-next.174",
// "svelte": "^3.43.0",
// svelte.config.js
server: {
hmr: {
host: 'localhost',
protocol: 'wss',
port: 443
}
} |
|
#2510 (comment)
I had a version that was working, updated that and tried so much the past few days.. nothing works.. uff.. how do you revert back to
Did you put this in the
Trying on Svelte 3.42.6 SvelteKit v1.0.0-next.178. vite: {
server: {
host: '0.0.0.0',
port: 3000,
https: {
key: readFileSync('/app.loc.key'),
cert: readFileSync('/app.loc.crt')
},
hmr: {
host: 'localhost', // or 0.0.0.0
protocol: 'wss',
port: 443
}
}
} |
|
@robots4life What I currently have in a working state is the following (your mileage may vary):
import preprocess from 'svelte-preprocess';
import host from 'vite-plugin-host';
import path from 'path';
import node from '@sveltejs/adapter-node';
/** @type {import('@sveltejs/kit').Config} */
const config = {
// Consult https://github.com/sveltejs/svelte-preprocess
// for more information about preprocessors
preprocess: preprocess(),
kit: {
// hydrate the <div id="svelte"> element in src/app.html
target: '#svelte',
adapter: node({
out: 'build',
precompress: false,
env: {
host: 'HOST',
port: 'PORT'
}
}),
vite: {
resolve: {
alias: {
$components: path.resolve('./src/lib/components'),
}
},
envDir: '../',
plugins: [host()]
}
}
};
export default config;
In my case there was no need to add anything other, neither any Edit: Updated to latest |
|
@taffit On linux, have @moisesbites Nada, even with the host added to the package.json the same result. Can confirm this was working in prior versions of Kit. Is ref: #1468 |
|
@robots4life https is a different beast. I assume, you set the certificates somewhere? Do you have some proxy that will terminate TLS and forward to your app? Or do you have some traefik-container? |
|
@taffit pinged you on Discord.. yeah I have a CA and auto-gen the certs, do a reverse proxy on port 3000, yeah, done plenty of hmr value experiments.. 😉 |
|
Using Devilbox - Docker remote environment, it works with this simple config, running /** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
// hydrate the <div id="svelte"> element in src/app.html
target: '#svelte',
vite: {
server: {
host: '0.0.0.0'
}
}
}
};
export default config;What confused me was that SvelteKit did work just fine with HMR under https://app.loc/ without having a port number in the URL in the past. Being able to tell Vite to use the cert from https://app.loc instead of making a new one for localhost on start could possibly fix this issue. There is an option for vite.server.hmr.server where I assume this could be solved however the option does not seem to work with a self signed cert so far. import { readFileSync } from 'fs';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
// hydrate the <div id="svelte"> element in src/app.html
target: '#svelte',
vite: {
server: {
host: '0.0.0.0'
},
hmr: {
server: {
https: {
key: readFileSync('app.loc.key'),
cert: readFileSync('app.loc.crt')
}
}
}
}
}
};
export default config; |
|
Got the same error using traefik + https with mkcert. |
|
Okay, finally I found the trick. So I don't even know how it works before version next This config solved the problem for me. (http) |
|
Hi everyone, Mostly leaving this for future readers, but I believe I have found a fix for people using sveltekit behind a TLS reverse proxy, with no local/native TLS in sveltekit it self. If you were previously running a config setting protocol, host, etc, you must strip the config down to just this: This fixed the issue for me, and sveltekit no longer loops infinitely. It seems like you no longer have to specify the host, local port, or protocol. My setup:
I hope this helps! |
|
The proposed fixes unfortunately still don't work for me 🥺 I'm running Nginx as a reverse proxy on port 443. Sveltekit is running on port 3000. Both are running locally currently. I adjusted the svelte.config.js as @Cidan described, but I still get the endless reloading when I visit https://mydomain.com. Could someone who has fixed it, please post his Nginx config? |
But i did a long time ago xD |
I'm running nginx and the svelte app in Docker. svelte config: Dockerfile for svelte app: Container config (docker-compose): |
|
@annmarie-switzer this config then runs on https://localhost/ or https://myapp.loc or https://myapp.loc:3000 ? |
|
I have been able to get rid of this issue and keep HMR when running through Docker Compose in WSL2 behind Traefik with the following setup: docker-compose.dev.ymlclient/Dockerfileclient/package.jsonclient/svelte.config.jsThe site is then available on |
|
Thank you very much for your help! 😊 I got it working 🥳 I have following setup on my local machine:
If you have a similar setup, here is what you need to do: 1. Adjust your nginx.conf Make sure to adjust the paths to your certificate and private key file. If you want to create a self-signed certificate for local testing, you can use this command:
Don't forget to reload your config after you have done the changes:
2. Adjust your svelte.config.js
Just restart SvelteKit and you are good to go:
From now on you should only use https://localhost, because http://localhost:3000 won't work with HMR. *Thanks again everyone for your help ❤️ |
|
Chiming in here as I develop with Remote VSCode frequently on a SvelteKit project and I have never run into this issue, including with ports automatically forwarded. While what I'm suggesting is not a solution to the issue itself, it may help people securely (and quickly) develop over SSH with VSCode session depending on your situation. I see many people suggesting to use a reverse proxy, or to modify their UFW firewalls. This should not be necessary and may expose your personal or development machines unnecessarily. These types are things are easily solved with VPNs. I highly recommend using something like Tailscale. It is a fantastic piece of software and is free for personal use. It takes no more than 10 minutes to get setup. All you need to do is create an account and install Tailscale on the machines in your network. With that, you now have a fancy new zero trust private network! Confirm by trying to ssh into the other machine on your network. If that works, VSCode should be good to go without any of these issue. HMR should work normally, pages should load quick, and ports should automatically forward. PS: Here's their repo. |
|
Ahh, finally. The endless reload has taken a break.
kit: {
// hydrate the <div id="svelte"> element in src/app.html
// target: '#svelte'
vite: {
server: {
hmr: {
port: 3000,
clientPort: 3001
}
}
}
}
|
|
Would anyone be up for taking a stab at adding a FAQ entry that explains what the issue is and how to resolve it (ideally in a tool-agnostic way)? https://github.com/sveltejs/kit/tree/master/documentation/faq |
|
This was a bug I fixed (at least mostly) in Vite 2.9, so I'm not sure we necessarily need an FAQ as it wasn't really user confusion, but a bug |
benmccann
added
bug
|
Just for future reference, i was getting stuck using vite version 5.0.3, installed latest version which is 5.2.4 and worked fine. |
and others
Describe the bug
Endless reloading by start it from VS Code Remote-SSH terminal:
npm run dev -- --open(open
localhost:3000on local computer and svelte is running on remote)Termorary solution:
With
--hostit works great:npm run dev -- --host --open(open
111.222.333.444:3000(server ip) on local computer and svelte is running on remote)Other projects works fine on the same server with same VS Code Remote-SSH,
sapper-template, for example. Problem (for me) only with SvelteKit now.Logs
Please include browser console and server logs around the time this bug occurred.
To Reproduce
pnpm init svelte@next my-apppnpm inpm run dev -- --openExpected behavior
Work on VS Code Remote-SSH with port forwarding without endless reloading.
Stacktraces
If you have a stack trace to include, we recommend putting inside a
<details>block for the sake of the thread's readability:Stack trace
Information about your SvelteKit Installation:
Diagnostics
The output of
npx envinfo --system --npmPackages svelte,@sveltejs/kit,vite --binaries --browsersSystem:
OS: Linux 4.15 Ubuntu 18.04.4 LTS (Bionic Beaver)
CPU: (2) x64 Intel Xeon E3-12xx v2 (Ivy Bridge, IBRS)
Memory: 98.10 MB / 984.89 MB
Container: Yes
Shell: 4.4.20 - /bin/bash
Binaries:
Node: 14.16.1 - /usr/local/bin/node
Yarn: 2.0.0-rc.27 - ~/.npm-global/bin/yarn
npm: 6.13.7 - ~/.npm-global/bin/npm
npmPackages:
@sveltejs/kit: next => 1.0.0-next.80
svelte: ^3.29.0 => 3.37.0
Your browser
Chrome 88.0.4324.150 (Official), (64 bit)
Severity
Not critical, but it is incrase REPL from 1 second to 8 seconds :(
if i use the solution with adding
--hostas additional parameter.The text was updated successfully, but these errors were encountered: