Add docker based dev env

[Andykmcc]

To use the docker dev env you only need docker and git installed locally. git clone the the UI repo, cd into it, then run docker compose up. lastly open https://localhost:3000/ in your browser.

The vite "open" option that pops your browser open does not work in docker because of docker security model, the workarounds are ugly. If you still want a JS devX you can clone the repo and run npm run start:dev this just calls docker compose up but many JS dev, expect an npm based start up command. i think it is fine and we only use npm to call a script and i highly doubt the npm scripts API will change, so we don't really need to worry about what version of node/npm someone has installed. Since in theory all the node stuff happens in a container, which has its own node version specified, we could delete the .node-version file. ideally we only define a node version in one place in the project, right now there are few.

[Andykmcc]

out of date

The only thing this changes about the non-docker dev workflow is the browser no longer opening. im trying to fix that now but i think there is a bug in the vite cli

[Andykmcc]

The open browser feature when running vite directly on the host now works the same as it does on main. Running npm start starts the vite server and pops open your browser. running docker compose up starts the vite server in a container but doesn't open your browser because it cant.

There is a werid bug i keep getting when i run npm start where my terminal seems to be in some type of escaped mode. my keyboard input doesnt get passed to vite or even the shell. hitting ctl + c doesn't kill the vite process. This doesn't always happen, maybe 2 out of 3 times. Given that the vite config is functionally equivalent to main i dont think this issue has to do with my changes. maybe its a zsh thing?

[Andykmcc]

@rsarathy FYI, in case you are interested in this kind of change

[Andykmcc]

You are correct. If we merge this, nothing changes about your current workflow. It's purely additive.

[graue]

Now you're turning on the same option again via the command line? Why?

[Andykmcc]

Docker runs its own subnet, without this you can’t access thing in a container from the host. I might be able to configure docker to use host networking. I’ve never done it and am not entirely sure it’s a thing, nor am I sure it would resolve the problem you’re talking about. That said, I get why in principal opening the port up network access is bad but in practice I don’t think this matter. So what if someone at a coffee shop can make get requests to your local copy of bikehopper UI.

[graue]

Can't you control this at the container level via some equivalent Docker option of where to bind?

[Andykmcc]

That is exactly what I mean by some kind of "host networking" option in docker.

[Andykmcc]

Change it so now docker will allow accept connection from the 127.0.01, the loopback interface (AKA the host machine, your laptop). Vite still needs to has the host option passed because the whole "host" flag in vite is how vite solves a problem that docker also solves, limiting access the open ports. so now the vite process is open to connections from the host but it runs in a container that only access connection from the host, not beyond the host.