|
|
|
|
@ -75,14 +75,22 @@ Once you have that you can make it your own: |
|
|
|
|
git init . |
|
|
|
|
go mod tidy |
|
|
|
|
cp config_example.toml config.toml |
|
|
|
|
make migrate |
|
|
|
|
sqlite3 .\db.sqlite3 ".read tools/pragmas.sql" |
|
|
|
|
make migrate_up |
|
|
|
|
sqlite3 db.sqlite3 ".read tools/pragmas.sql" |
|
|
|
|
make build |
|
|
|
|
make dev |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
This gets the site running and ready for development. You only need _to do this once._. After |
|
|
|
|
this, when you're ready to work just do: |
|
|
|
|
|
|
|
|
|
```shell |
|
|
|
|
make dev |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
## Configuration |
|
|
|
|
|
|
|
|
|
There's 3 basic moving parts to the whole system: `webapp.exe`, `ssgod`, `tailwind`, and `air`. |
|
|
|
|
There's 3 basic moving parts to the whole system: `webapp.exe`, `ssgod`, `tailwind`, and `ozai`. |
|
|
|
|
|
|
|
|
|
You can configure the `webapp.exe` using the `config.toml` which you copied over from `config_example.toml`. The options are fairly self-explanatory. |
|
|
|
|
|
|
|
|
|
@ -96,10 +104,30 @@ it run how you want. I use the `@apply` heavily because I'm a programmer and no |
|
|
|
|
ever tell someone they should sprinkle repetitive bullshit all over their HTML. Resist the |
|
|
|
|
authority. Use `@apply`. |
|
|
|
|
|
|
|
|
|
Finally, you can configure the [Air](https://github.com/air-verse/air) tool with `.air.toml` to make |
|
|
|
|
it work how you want. I configured it to only do a reload when I change `.go` code. This works |
|
|
|
|
better because build times for Go on Windows are heinously slow for some reason, and even on |
|
|
|
|
Linux/OSX it's still slower than just letting `tailwindcss` and `ssgod` do their own auto-build. |
|
|
|
|
Finally, you can configure other processes to run with [Ozai](https://lcthw.dev/go/ozai) in the |
|
|
|
|
`.ozai.json` file. Why so many different formats? I'm still learning which is best to use and while |
|
|
|
|
I like TOML I think I may go with `.json` files to reduce dependencies. You tell me though. |
|
|
|
|
|
|
|
|
|
## Ozai Autorestarts |
|
|
|
|
|
|
|
|
|
Ozai is a simpler tool that doesn't do auto restart. Instead it will create a little webserver at |
|
|
|
|
`http://127.0.0.1:9999` with endpoints you can hit with curl to force a restart. Look in the |
|
|
|
|
.ozai.json file to see what's configured. This makes it easy to simple add a `curl` call in your |
|
|
|
|
build process and kick everything over. Look in the `Makefile` for how I do this. |
|
|
|
|
|
|
|
|
|
This works better than the way `Air` does it for a few reasons: |
|
|
|
|
|
|
|
|
|
1. You can run your build like normal in your own IDE or build tool and see your errors directly. |
|
|
|
|
When you use other autobuild tools they have the errors so you can't access them. |
|
|
|
|
2. You get an immediate restart after your build succeeds, rather than waiting for an external tool |
|
|
|
|
to detect you made changes, run the build, and then restart your browser. |
|
|
|
|
3. You avoid the "auto reload deadlock" where you run a build, the server is shutdown, but you hit |
|
|
|
|
refresh too soon, so now your browser waits for an error, then you have to refresh again. Way |
|
|
|
|
easier to just not use any of that. |
|
|
|
|
4. No more silent failures hiding inside your terminal that you can't see. Just manually restart |
|
|
|
|
it. |
|
|
|
|
|
|
|
|
|
For more, checkout the [Ozai Project](https://lcthw.dev/go/ozai"). |
|
|
|
|
|
|
|
|
|
## Tour of Directories |
|
|
|
|
|
|
|
|
|
|