Should web/serve/files.go be version controled?
tad-lispy opened this issue · 2 comments
Hello! Thank you for developing this useful tool.
I'm not a go developer so please excuse my ignorance. I am trying to package your program using Nix Flakes with hope of contributing the flake.nix file to your repository. Truth be told I'm also learning Nix, so bear with me 😁
I got some progress and was about to commit, but then I've noticed that when building or running tests web/serve/files.go got modified. Now I'm not sure if I should stage it or not. Looks like the file is generated:
Line 28 in 19e9fd8
So should it be committed to git? Or maybe it should be removed and ignored?
Currently files.go is generated and source controlled, so you should stage it. This isn't ideal but it's a temporary work around for users who get jd via go get github.com/josephburnett/jd. See #28
I wanted to include the web UI with the commandline tool because it's a nice alternative way to play with diffs. And it's live, so you can see the diff be produced as you type. The UI uses jd as a library, so it's the same golang code compiled to web assembly. Just a different main that runs in a browser. All the data stays in the browser too; it doesn't make any service calls.
The web UI is just three files (also hosted from a GCS bucket at http://play.jd-tool.io/). In order to include them in the jd commandline binary, I base64 encode those three files into a golang source file (similar to go-bindata) and include them. So when the library changes, the two binaries need to be changed: 1) the native golang main and 2) the web assembly main.
I would prefer the web assembly be generated on demand, which happens with make release. But it doesn't work with go get. I think there's a way to have go get run commands when getting files via special comments. That would let me remove files.go from source control. But for now, that's the work around.
I figured out how to remove this file from version control without breaking go get using a build directive. 05af9a9