UniversalViewer
Decide which additional repositories need updates (eg manifesto, manifold, external components etc)
Based on my notes below, since there is currently only one current consumer of Manifold outside of the iiif components and it's inactive since November 2024 I think we can potentially roll Manifold back into the UV. The iiif components mentioned at the bottom (base-component, av-component, etc.) all consume Manifold so we will need to roll those into the uv as well. Manifold is a wrapper around Manifesto that provides additional features but the UV appears to be the primary consumer of those features.
Presentation-3, Manifesto and Vocabulary should continue to be maintained outside of the UV. Manifesto and Vocabulary still use a "master" branch instead of main/dev etc., so that should be modernized in consistency with our other repos.
Consumed heavily outside the uv by other iiif-based projects:
@iiif/presentation-3
@iiif/manifesto
Consumed in a couple projects outside the uv:
@iiif/vocabulary - consumers: karl-kraus/wpn-static, SwissFederalArchives/chgov-brprotokolle-frontend
Few to no direct consumers outside the uv::
@iiif/base-component
@iiif/iiif-av-component
@iiif/iiif-gallery-component
@iiif/iiif-metadata-component
@iiif/iiif-tree-component
@iiif/manifold - consumer: waldenn/conzept (inactive since 11/2024)
Thanks, @Geoffsc, that's extremely helpful!
I think before we consider rolling @iiif/manifold back into the UV, we should consider whether that's going to be our long-term solution for state management, or if there's potentially a different solution worth considering. In my experience, the manifold dependencies are less entangled with the UV's other dependencies than the other external repositories, so that one might be more work to re-incorporate than to keep separate, especially if there's a replacement on the horizon. I'd also say that "inactive since 11/2024" is less than a year, so it seems at least possible that activity could resume there -- more reason to at least save manifold for last and focus on the rest ahead of it.
All of the *-component dependencies seem potentially worth re-incorporating, though, since there's currently significant overhead in maintaining them separately, especially if no one is using them. It may be interesting to think about whether there's a mono-repo sort of approach that might be feasible for sharing out components independently in future, should that need re-emerge.
As @K8Sewell pointed out during today's standup, we may also need to take a look at @universalviewer/aleph and @universalviewer/uv-ebook-components, both of which are dependencies of the UV that live outside of the main universalviewer repo but which are under our control (and in some cases, have outdated dependencies that need attention). I think it makes sense to open tickets to investigate both of these things.
In the meantime, my recommendation for actions to take in the next sprint based on @Geoffsc's research so far:
1.) For @iiif/manifesto and @iiif/manifold, adjust the existing repositories to match the standards of the main UV (in terms of branch names, tooling, GitHub actions, etc.).
2.) For all of the @iiif/*-component repositories, fold the code back into the main UV repo and archive the separate repositories. Since these are all using relatively outdated technology, maintaining separate repos adds a lot of overhead, and it feels unlikely that others will adopt them in their current form. I do like the idea of having shared components outside of UV, but I think we need to rearchitect a bit before we try that again (and, as noted elsewhere, it might be achievable through a monorepo design of UV, instead of through actual separate repositories).
Next Steps
Group A: Components that need discussion that are within UV repo
- [ ]
@universalviewer/aleph - [ ]
@universalviewer/uv-ebook-components
Group B: Components that need updates that are outside the UV repo
- [ ]
@iiif/manifesto - [ ]
@iiif/manifold - [ ]
@iiif/presentation-3 - [ ]
@iiif/vocabulary
Group C: Components with green light to fold back into UV
- [ ]
@iiif/iiif-metadata-component- PR ready for review - https://github.com/UniversalViewer/universalviewer/pull/1463 - [ ]
@iiif/iiif-gallery-component- PR ready for review - https://github.com/UniversalViewer/universalviewer/pull/1472 - [ ]
@iiif/iiif-tree-component - [ ]
@iiif/iiif-av-component - [ ]
@iiif/base-component
A couple of thoughts on "Group C":
1.) We should do @iiif/base-component last, since all of the other components depend upon it.
2.) I'm a bit concerned about @iiif/iiif-av-component -- while the other components are small, self-contained, and easy to reintegrate, the AV component is large and complex, and it may be more challenging to address. I'm not sure who has expertise in that codebase at this point -- I do not use it and have never worked with it, so I'm not eager to take on responsibility for it. This may be one of those situations where external modularity has some real advantages, though wherever the code lives, somebody needs to maintain it if we are to continue to incorporate it, and I know there is still a need at some institutions. I guess this should be second-to-last on our list, and we should have a conversation about it in the meantime.
Closing due to overlap with other open issues, see #1380 for next steps
