In Apr 2019, I started gojq project, which is a Go implementation of jq command and library. The development is still going on and recently I released version 0.12.1.
The Homebrew formula of gojq has been distributed from itchyny/tap, but recently it was moved to homebrew/core. So now you can install with the following command.
brew install gojqThe formula was added to homebrew/core without communication with me and it surprised a lot. The quality of the formula was not good at first, but they improved as I pointed out. Generally speaking, it is appropriate to contact with the main developers when we add a new distribution of the software.
When we move a formula between taps, we use tap_migrations.json . On finding the new tap written in the JSON file, brew automatically detects the formula was moved. Now gojq has been moved to homebrew/core, the JSON file looks as follows.
{
"gojq": "homebrew/core"
}The gojq project has been much improved recently. I receive interesting corner-case bugs constantly. For example, gojq exits with failure when $HOME is unset (#58). I didn’t expect this to happen, but on AWS Lambda the variable is surely unset. The program should ignore the error on expanding the default module file ~/.jq .
I also use fuzzing to find bugs of gojq. Some crashing bugs have been found; ""[:{}] or infinite * "x" . Also, interesting bugs in the lexer have been found recently; 1?/1 (which is a valid query but failed due to an offset bug of the lexer), 0.._ (which is an invalid query but accepted due to a bug of scanning a number). Even if I think some software is well tested, fuzzing brings me a new bug. This reminds me how fuzzing is important in software development.
Since gojq v0.12.0, it implements the JSON-coloring code in its project. In the previous versions it used the go-prettyjson library. But this library has a bug with escaping the object keys (fixed by #15), requires normalization of NaN and infinities which causes overhead, and the performance was not good. By implementing the marshaler in gojq repository, it can be specific to the jq-flavored encoding (especially for NaN and infinities) and reduce the overhead of normalization. Also it reduces the memory allocation with performance improvement by 3 times. I don’t use go-prettyjson for gojq anymore, but the performance of the library will be improved by #17.
About two years have passed since I started the gojq project. I leaned a lot from the project and still educational for me. The library has been imported by various Go projects. I would like to keep maintaining and enjoy the project.
