Luckily, Go has a function that does most of this for me: filepath.Walk I just needed a proof of concept so I could move forward with the rest of the steps and get something working. The first version didn’t really need anything special, like extensions to ignore. I needed a function that could recursively look at all the files in a directory looking for any that have changed since a given timestamp. The final version ended up taking a few more steps than this, but these turned out to be a pretty good starting point.
I realize there are other live reloading tools out there, and many of the support polling, but I still felt writing my own was the best option in this particular case as it would get me exactly what I needed in a relatively short amount of time. I decided that a library would be best, then I could just write a quick (~50 lines) main.go file to use it for each project in the future. I examined my options, and eventually decided to just write a custom live reloader that uses polling. All of this meant that I needed a solution and couldn’t go back to my old ways. This helps avoid any support issues where everything works on one OS, but has some subtle bug in another ( I’m looking at you, Windows!) while also making it easier for newcomers to get things up and running quickly - you just need to have Docker installed. As many of you know, I create programming courses, and one of the reasons I was so vested in getting this local docker setup to work is because I want to offer docker-compose configs for all of my new courses. Unfortunately, that wasn’t going to cut it in this situation. This has proven to work well for me because modd can handle most prep tasks I need done and is also great for running tests after file changes.
In the past that has been running modd locally and not using a container for my local Go app. I’m a fairly pragmatic guy, so at this point my next step would typically be to minimize wasted time and revert to a tool I knew would work. I was trying to setup a docker container for development and ran into an issue - no matter what I tried, file change events weren’t being propagated to the container, so I couldn’t get hot/live reloading to work.Īs you can imagine, this was pretty frustrating developing while having to manually stop, rebuild, and restart your application can already be time consuming enough, but toss in a docker container and a few extra steps and suddenly this process can feel like it is devouring your entire day.
#LIVERELOAD GOLANG CODE#
Trying to kill cmd Įvent: "/app/go/api-server/app/auth/auth.Creating a Live Reloader in Less than 200 Lines of Go Code Here is a log with the debug flag on: make: Entering directory '/app/go'Įvent: "/app/go/api-server/app/auth/auth.go": CHMODĮvent: "/app/go/api-server/app/auth/auth.go": WRITE I've observed that sometimes air fails to kill the previous version of the process and tries to start a new one and fails. but I don't see other alternatives as listing processes in Go seems to be a nightmare. (also it doesn't even seem to return the executable path). I don't think it would be a good idea to try to parse TASKLIST as the language might change per system, etc. If that doesn't work, maybe try to get the PID by executable path? Is that even possible? If so, just check it against c.Build.FullBin and use that on TASKKILL. Is start /b even necessary? I'll try to modify the code and run some tests without it. I'm thinking of a good way to fix this, since just TASKKILLing the process by name isn't a good idea. When trying to run the TASKKILL command manually, I noticed the following error: ERROR: The process "#" was not found., which confirms my suspicion.
#LIVERELOAD GOLANG WINDOWS#
Hello! First of all, thank you for this awesome package :)ĭue to Air's current implementation of starting processes on Windows (with start /b), the PID returned by is of a process that already exited ( start's PID, not what it started), hence the debug error failed to kill PID #, error: exit status 128 is returned.
0 kommentar(er)
