UniversalViewer
Configuration documentation
It would be helpful to have documentation of each config option, what it does, and most importantly (IMHO) where it's used so that developers wanting to work with the option know where to focus their efforts.
PRs that use/affect any config would have to also include matching documentation updates to be approved.
A general config overview would also be helpful and tie in with #1376 to explain how config is loaded, applied (default vs runtime), and accessed in code - there's a few different ways used in code and it's never clear which works/is correct/best. I personally often have to just find an existing use and copy it, which isn't always present, meaning time wasted on trying different approaches.
I started this a while ago, but there's still a lot to do and it needs updating for recent PRs: https://github.com/Saira-A/configdoc/blob/main/options.md
Great @Saira-A, I like the idea of putting it in a docs template too.
If we do want to go as far as noting where each option is used (extension/file/function/other specifics) we could maybe create a new repo and sub-task each config option allowing a bunch of us to divide the work so one person doesn't get utterly bored doing the lot :)
I believe it was @edsilv's original intention to document all of the configuration options by creating explicit types for the configurations, and including descriptive comments on the types to explain all of the options. This is currently being used to autogenerate the documentation at https://docs.universalviewer.io/modules.html
Obviously, that autogenerated documentation is presently very hard to navigate and understand, so I am not claiming the present situation is ideal -- but I do think we should be careful not to duplicate effort if we can possibly avoid it. I wonder if there's a way to auto-generate the proposed documentation by using existing code comments (and perhaps the help of some new annotations). I like the idea of linking the code and the documentation explicitly, because this makes it harder for things to gradually get out of sync or become inaccurate... but I do understand and agree that more readable and human-curated documentation would offer a better experience!
as discussed in sprint 3 inception, sub issue #1391 removed and will be addressed at a later date
