filter only localhost ports

[kvart714]

Netstat finds different ports for me but only one of them is localhost so I added an additional condition

[joshbolduc]

Thanks for the PR! I'm glad this helps, but I think it might not work in general because you can have the dev server use an arbitrary host using the -h flag.

I'm not sure why you're seeing this in your case, but there is a general problem with the existing port detection logic in that it kind of assumes only one port will be opened. Since a launch script can do conceivably anything (including launch other services on other ports, which may listen on localhost), I think what may ultimately be necessary here is more selective logic around detecting that a particular port is actually hosting a Storybook dev server before committing to it.

There may also be another bug here where we are falsely detecting ports as "open" when they're really not--if that's the case, then the above is still an issue, but it may be uncommon enough that (with a different fix) we can still avoid the false positives.

[kvart714]

hmm... it might be easier to just let the user specify the port in the settings also, perhaps you could parse the output of the task.

[kvart714]

@joshbolduc I'm still facing this issue and it's annoying.

I see in the code that after defining the port, we use the hardcoded "localhost":

        .then((port) => {
          const url = `http://localhost:${port}`;
          logDebug(`Detected Storybook server URL as ${url}`);
          this.urlMailbox.put(url);
        })

So filtering ports by localhost looks right for me. Please describe the correct solution in more detail. I can try to implement it.

[joshbolduc]

The hardcoded localhost isn't ideal. I think it would be better if we tried to detect the host (and not just the port) and not assume localhost. Even though it's hardcoded right now, I'm concerned about filtering on localhost/127.*.*.* because that approach would only work as long as we kept using a hardcoded server URL.

I think the most robust solution to the "wrong port detected" problem would be to try to verify that a given port is actually running a Storybook server before selecting it.

Right now the logic is something like:

1. poll for the launched process (or a child) to open a port
2. assume the first such port is the Storybook dev server, and stop polling
3. wait for the presumed dev server to start returning 200

when it should actually be more like:

1. poll for the launched process (or a child) to open a port
2. for each port detected, try to ascertain whether it might be a Storybook dev server (this process might itself require polling)
3. continue checking for new open ports/polling discovered ports until a Storybook dev server is positively identified

I'm not yet sure the best way to test whether a given port might host a Storybook dev server, even after it's started up. There might be a tell-tale response header or some well-known file path, or something else about the response that is stable enough (across past and future versions of Storybook) that it would distinguish Storybook vs. some other random server. It doesn't have to be perfect--I don't think it's that common to have to pick from multiple ports, so false negatives would be a bigger problem than false positives.

(That said, I am still curious to know what's responsible for the other open port in your case--i.e., is the extension finding another legitimate open port that the Storybook process or a related process has opened, and it just picks the wrong one since it can't tell them apart? Or is there some other detection or parsing bug that makes it seem as if there's another open port?)