Dev environment setup?

[rageshkrishna]

Is there any documentation on what's needed from a dev environment? My situation is that I've cloned the repo in WSL and tried to run npm run ci-tests. I immediately had a bunch of failing tests because several *.localhost domains don't resolve, like this:

FetchError: request to http://another-subdomain.localhost:8000/ failed, reason: getaddrinfo ENOTFOUND another-subdomain.localhost

So I added whatever I could find in the tests to my /etc/hosts:

127.0.0.1       test.localhost
127.0.0.1       another-subdomain.localhost
127.0.0.1       test-subdomain.localhost
127.0.0.1       bypass.localhost
127.0.0.1       other.localhost

which got me to 540 passing tests and 8 pending. I now see this:

18 05 2023 10:05:21.251:INFO [karma-server]: Karma v6.4.2 server started at http://localhost:9876/
18 05 2023 10:05:21.251:INFO [launcher]: Launching browsers ChromeHeadlessWithCert with concurrency unlimited
18 05 2023 10:05:21.254:INFO [launcher]: Starting browser ChromeHeadless
18 05 2023 10:05:21.254:ERROR [launcher]: No binary for ChromeHeadless browser on your platform.
  Please, set "CHROME_BIN" env variable.

So I was wondering if there's a doc or checklist of some sort that could help me get up and running. Thanks!

[pimterry]

This is a good point @rageshkrishna! To be honest, I'm not sure - I don't use Windows much myself. The tests do run with very minimal setup on a fresh Linux box, e.g. they pass in CI with no special configuration at all: https://github.com/httptoolkit/mockttp/blob/main/.github/workflows/ci.yml. I believe that includes GitHub's default setup (e.g. a normal Chrome install, which is sufficient for Karma to detect it - solving your 2nd issue) but nothing more.

I wasn't aware that the *.localhost domains wouldn't resolve within WSL, I'm a little surprised as I thought that was fairly standard. Do you know if that's a WSL issue, or Windows in general? We could probably work around this, or at least detect it and automatically instruct users how to fix it (and probably reduce the number of hosts used en route - I doubt we need all those different distinct names).