Windows/WSL port issues

[Conduitry]

A DISORGANIZED BUNCH OF FINDINGS BEFORE I GO TO BED:

Under Windows Subsystem for Linux, multiple processes can bind to the same port (or multiple bindings from within the same process), and there is no error thrown. It seems the first one to do so is the one that handles all of the requests. If one ends, the next one seamlessly starts handling the requests.

Because of this, port-authority's mechanisms for checking for port availability do not work on WSL. I was able to get the unit tests to pass by attempting to connect to servers rather than trying to create servers. In particular

// check.ts

import * as net from 'net';

export function check(port: number) {
	return new Promise(fulfil => {
		const client = net.createConnection({ port }, () => {
			client.end();
			fulfil(false);
		}).on('error', () => {
			fulfil(true);
		});
	});
}

// find.ts

import * as net from 'net';

export function find(port: number): Promise<number> {
	return new Promise((fulfil) => {
		get_port(port, fulfil);
	});
}

function get_port(port: number, cb: (port: number) => void) {
	const client = net.createConnection({ port }, () => {
		client.end();
		get_port(port + 1, cb);
	}).on('error', () => {
		cb(port);
	});
}

HOWEVER, ALL THAT SAID:

I think this is separate from the issue I'm seeing when I try to run svelte.technology locally. The (node:413) UnhandledPromiseRejectionWarning: Error: timed out waiting for connection error occurs regardless of the above changes (which isn't too surprising, as that is thrown by wait(), not one of the two functions I had to change to get unit tests to pass). But, despite that error - and I missed this before - despite that error, svelte.technology is still being served on port 3000. But live reloading doesn't work.

ALSO:

When I clone the latest sapper-template and run it with latest sapper (0.10.1), all ... seems well? No error about timing out waiting for the connection. App is served on port 3000. Live reloading works. This is without any of the above changes to port-authority.

SO:

svelte.technology has Some Issues, but I don't think they're related to WSL's weird handling of ports. I don't know whether it's the older version of a sapper, or something else, or what. I was getting a strange console exception Failed to execute 'fetch' on 'ServiceWorkerGlobalScope': 'only-if-cached' can be set only with 'same-origin' mode, which I have no actual evidence is related.

sapper-template/sapper seem fine on WSL. If other people are still having problems, I'd like to hear about them. By which I mean I suppose I'm resigned to hearing about them.

However, that said, the port-authority issue on WSL remains. As is, sapper will happily serve additional apps on port 3000, which will be inaccessible until earlier apps are terminated.

WHAT ABOUT ON WINDOWS WINDOWS, NOT WSL:

Maybe another time, I'm going to bed.

TL;DR:

As far as I can tell, port-authority is a problem, but not a huge problem. svelte.technology has problems, but they seem to be their own thing, not inherited from sapper/sapper-template.

[Conduitry]

OKAY SO WHAT ABOUT ON WINDOWS WINDOWS:

port-authority passes its unit tests unchanged on Windows. It also passes them with the above changes to fix the issues on WSL.

svelte.technology seems the same issues on Windows as it does on WSL - namely, the timed out waiting for connection error, and the lack of live reloading.

Latest sapper/sapper-template also seem fine on Windows. Live reloading works. port-authority works, in that it selects port 3001 if another sapper app is already on 3000.

SO:

This is exactly what I had hoped would happen on Windows. It means the svelte.technology issues are not specific to WSL, and it means that the port-authority issues are specific to WSL, and that sapper/sapper-template doesn't seem to have any of its own issues on either.

I don't really have any specific ideas about how to fix svelte.technology, but I do about port-authority on WSL. Attempting to connect to a port to see if it's available rather than attempting to start a server there is considerably slower. So I think a good solution would be to have port-authority attempt to open a server at a port (does't really matter which one), and then to attempt to open another one on the same port. If either fails with EADDRINUSE, we know we're not facing the WSL issue, and so we can continue with the existing logic. If they're both successful, we instead switch to the logic above where we attempt to connect to the ports. I'll try to open a port-authority PR to that effect later today.

[Conduitry]

port-authority PR opened. I don't think there's anything else specifically to do here for this issue. svelte.technology-specific stuff should be handled in that repo.

[Rich-Harris]

Maybe it really is timing out on svelte.technology? Seems unlikely — it defaults to 5 seconds, which is a lot — but it's possible. What happens if you bump it, by replacing ports.wait(PORT) with

ports.wait(PORT, { timeout: BIG_NUMBER })

?

[Rich-Harris]

(But I agree, there's probably nothing more to do here — will close this. Thanks)

[Conduitry]

The svelte.technology app is getting served right (ish) away, even without any 'you app is now on localhost:3000' message. If I increase the timeout port-authority uses, it's still served right away, but then the same timeout message from port-authority comes, just later. I'll have to look more at this another time.