Hugo Documentation Tool

I’m a big fan of Go so Hugo is a great tool and I’ve been having a lot of fun with it. I’m not sure I’ve taken much advantage of the Go bit aside from using a great tool in go. Can you extend hugo with go plugins?

Anyways, in the past I’ve used docusaurus which is a great tool to generate docs but after a while it gets tiring getting all the JS security alerts. I’d much rather use hugo.

Questions:

  1. Is anyone using go to deliver a pretty documentation site and have any examples of what you’re doing?
  2. I know lunar.js is one pattern, but how are people handling the hugo searching limitations ?

you can have a look at the … gohugo doc for example : GitHub - gohugoio/hugoDocs: The source for https://gohugo.io/

Hi, a lot of the docs in the cloud-native world are built using Hugo, for example, Istio / Docs , Getting started | Kubernetes , and many others. There are themes and sites that support client-side search using lunr or a similar tool, while others use Algolia as a service (see for example the docsy theme).

As for Go plugins, they are not supported according to this thread.

Thanks for the info that’s useful though one question. It seems like Hugo only maintains 2 iterations of the documentation. Current version (master) of next version (next branch). Is there any thought on supporting multiple version drop downs like for example: https://docusaurus.io/ Please note the version drop down at the top of the page where you can select which version of the docs you’re interested in.

I’d be curious to know even how we’d go about adding that type of support. It does complicates things but it is very nice for some projects to have historical versions you can navigate to.

It’s in the making for Doks (available in the near future):

Snag_5725660

1 Like

Ooooh, that’s beautiful.

Out of curiosity, if you finalized how you’re managing the deltas between versions I will be curious to know what your solution is.

One of the drawbacks of the previous tool I used was that it wasn’t easy to make changes to the documentation after you cut a release. Meaning if there was a spelling mistake in version 1.0 and we’ve already shipped to version 1.1, it was really difficult to do a fix and deploy its and have it be reflected in the previously released version.

That aside, I’m really excited about the prospects of seeing the final version released.

Thanks!

Yes there are a number of ways to do this. Since it’s more of a preferred process, I was thinking of writing a setup guide for a number of possibilities, e.g. proxying branch deploys using Netlify, and duplicating versioned documentation content (single repo setup).

That’s indeed very pretty.

Is it in your plans to make Doks multilingual?

Like versioning, it’s also in the making + part of the upcoming Doks release!

It will look something like this:

Snag_262f6ad

2 Likes

I think multiple branches would be interesting. I’d love to see if there’s an alpha release would love to test this out.

1 Like