Adding support for multiple documentation sets

[myrthos]

My use case is the following:
I am planning to have a site with multiple projects. Some of these projects have documentation.
This means I have more than one documentation set that are not related to each other. I would like to show them all on the same site, but not all the documentation sets should be visible in the TOC. There should only be one documentation set visible in a TOC.
It should be possible to navigate to a specific documentation set.
I only plan to have one version of each documentation set (the latest).

I did manage to accomplish this by 'abusing' the versioning of documents.

I created this structure (for testing purposes) in content/docs:

docs

• project1
  • section1
    • chapter-1.md
    • chapter-2.md
  • section2
    • chapter-21.md
    • chapter-22.md
• project2
  • project-A
    • chapter-A1.md
    • chapter-A2.md
  • project-B
    • chapter-B1.md
    • chapter-B2.md

The names of the folders and files are rubbish. I just created them to make sure I have unique names everywhere, so I can check the navigation is going in the right way.

Then I created the files data/docs-project1.yaml and data/docs-project2.yaml, with in them the TOC for each of the two projects.

In params.toml I added this:

[[docs.releases]]
    label = "First Project"
    url = "/docs/project1"

[[docs.releases]]
    label = "Second Project"
    url = "/docs/project2"

This works. The dropdown menu is shown and I can navigate each of the documentation sets. So, my use case can be realized. The only thing I want next is a landing page with a list of all the documentation sets.

As I am 'abusing' the versioning system, it is a working solution, but perhaps not an ideal one.

It would be great if this use case would be supported. If not, I do have a solution that is workable for me.
Also if you think there is a better way to realize this, I'm all ears.

[markdumay]

Nice! It’s certainly a creative way of using the versioned documentation. Another approach would be to have separate (documentation) sites / repos for each project, with the benefit of complete isolation.

But as long as you’re interested in maintaining the latest docs for each project only, I see no reason not to go ahead with your solution.

checkVersion will not work (and doesn’t make sense), although I do believe the semver check is flexible enough to accept your labels.

Do you have a specific feature request for the Hinode library right now? Or are you merely looking for a confirmation to support your use case?

[myrthos]

If you would have felt there would be some issues that would make this solution not so practical for my use case, I would indeed have a feature request :)
But as you basically confirm this as a viable solution, I do not have a feature request (I probably also should not have used that label).

I thought about using a subdomain per project, given that there is also a separate repository per project and having a main site for the blogs and the overview of the projects/documentation, but it is also more maintenance. Although the template on all those subdomains would be the same.
Have to think about that. Thanks for suggesting it.

[markdumay]

Yes, I can't think of any major issues right now. I can only imagine linking to the right page (relref or ref) might be cumbersome when you have a lot of similar pages / titles per project.

BTW, I migrated the issue to GitHub discussions and updated the label.

[myrthos]

For completeness, I have encountered a few minor issues with the approach I suggested, which I also resolved. So if anyone is interested in this solution to have multiple documentation sets, please read this page. It has the latest update on the current solution.