Decide which additional repositories need updates (eg manifesto, manifold, external components etc)

[LlGC-szw]

[Geoffsc]

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)

[demiankatz]

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.

[demiankatz]

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).