Using go/parser requires a built binary of the code to be enum'ed to
exist. This leads to two problems:
1. The binary may be very out of date with the code, for example, when
pulling into an existing repo that was last built locally some time
ago, running jsonenums on newly added files will fail;
2. If the binary has never been built, but the code already expects
the output of jsonenums, it will be impossible to generate the enums,
making it impossible to build the binary.
In response to a similar issue, Alan Donovan of the Go team suggested
that instead generating tools should be using (the not-yet stable)
x/tools/go/loader package to parse the actual Go code itself rather than
the compilation output: https://github.com/golang/go/issues/11415
This change uses the suggested approach to break the bootstrapping
dependency cycle.
package's ParsePackage to take prefix and updated related skip
conditional. Also updated args in call to ParsePackage within
server. Last paragraph of main package comment was updated, along
with the second to last paragraph of readme.
Since a fenced code block (three backticks) is already used, there's no need to indent code blocks. Either a fenced code block or an indent alone is enough.
Also use tabs instead of spaces in Go code to make it gofmt-compatible, and use Go syntax highlighting for Go code blocks.
Unlike 1e1ffecf4f148c30fb214feeb491c7de5fe54e56, only use Go syntax highlighting for complete Go code block, since GitHub renders it poorly for partial Go code.
