You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
3.2 KiB
64 lines
3.2 KiB
# zedshaw.games
|
|
|
|
This is a learning projects for me to learn Go. It's a simple website that serves past stream
|
|
information, a place to post links during stream, and the games I've made while live streaming.
|
|
|
|
## Getting godoc To Work
|
|
|
|
There's a built-in command `go doc` but there's also a more advanced tool by Google called `godoc`.
|
|
I know, amazing naming. Anyway, to get it you do this:
|
|
|
|
```shell
|
|
go get --tool go.googlesource.com/tools/godoc@latest
|
|
```
|
|
|
|
You can then run it and start indexing everything you've installed and _also_ yourprojects packages,
|
|
plus get a nice web browser based search page to view the docs:
|
|
|
|
```shell
|
|
go tool godoc -http=localhost:6060 -index
|
|
```
|
|
|
|
> ___NOTE:___ Google doesn't know how the internet works so you have to use `localhost:PORT` and not `127.0.0.1:PORT` when you run this.
|
|
|
|
After that it'll take some time to index everything but you can already start browsing the APIs you need, and your project's stuff is in the _Third Party_ section.
|
|
|
|
## Dealing With Module Bullshit
|
|
|
|
The way to think about Go's modules is that they don't have modules, they have "projects." Every
|
|
directory's .go files export all of their functions without any namespacing based on the file's
|
|
name. So if you put `FooBar` into `tools.go` and `Dipshit` in `fuckyou.go` then your namespace for
|
|
_all_ files has raw dogged `FooBar` and `Dipshit` without any reference to `tools` or `fuckyou`.
|
|
|
|
That's because your root directory is a whole __project__, not a module. To then create a namespace
|
|
you have to make a directory, place the files in that directory, and add `package mymod` at the top
|
|
of those files. You then have to import this as if it's an __entire fucking project__ everywhere
|
|
you want to use it:
|
|
|
|
```go
|
|
import 'mywholewebsite.com/rootproject/subproject'
|
|
```
|
|
|
|
In this case you have a directory `subproject` and in there are a bunch of .go files with `package subproject` at the top to indicate they are in that subproject. Thinking about Go's modules as separate projects helps to sort out this `import` statement.
|
|
|
|
1. mkdir tools
|
|
2. Create files in tools/ with `package tools`
|
|
3. `import "zedshaw.games/webapp/tools"` to get the subdirectory
|
|
|
|
## Why Did Go Do This?
|
|
|
|
That's because it comes from Google, and Google is famous for two things:
|
|
|
|
1. Using a monorepo.
|
|
2. Assuming everyone else uses a monorepo.
|
|
|
|
Don't believe me? Go look at the official first document [covering modules](https://go.dev/doc/tutorial/create-module) and you'll see they create two _totally separate projects at the root which then link to each other_. That's not how anyone else thinks when they make a single project to work on, but if you're suffering in monorepo hell you'll do it this way.
|
|
|
|
I'll also posit that Google has some weird incentive that measures numbers of projects in the
|
|
monorepo as some kind of metric for employee productivity, so everyone working there is motivated
|
|
to get as many little projects into the monorepo as possible, thus a great way to get them to adopt
|
|
Go is to make Go support pulling tons of random projects from the root of a monorepo.
|
|
|
|
So that's why you have to put your whole entire domain name into the import, and why you have all
|
|
the functions just raw dogged into your face when you make multiple files, and why subdirectories
|
|
are treated like whole little projects.
|
|
|