Library Service Refactor and Cleanup

Problem/Motivation

As it exists as of the Beta 3 release, the Library service (patternkit.asset.library) has a number of issues that could benefit from added attention and refactoring. The original intent of this class was as a demonstrated resolution to issues described in #3154343: [META] Update Asset Libraries and Discovery to use a Plugin System, but in practice it has some shortcomings. Key among these issues and opportunities for cleanup, are the following:

• The CacheCollector functionality is not properly implemented since library definitions are being indexed by library name instead of extension name. This results in the get() method being used inconsistently, and the resolveCacheMiss() method to always kick off full discovery across all modules before persisting an individual result to the discovery cache.
• Since assembled library definitions are not tied in any way to their providing extensions, the getLibrariesByExtension() method results in a full discovery across all modules and then only returns the first library defined by that module which is inconsistent with the method documentation.
• Access to pattern definitions that have been discovered requires a reload and parse through all library definitions again, when instead, this could realistically be cached on its own.
• The library service attempts to handle responsibility over too many things, including library file parsing, library definition creation, library overrides and altering, caching, pattern discovery, and pattern resolution. Maintaining all of this in a single class makes for a very complex implementation and makes things much more difficult to trace and debug.

Proposed resolution

To address these issues, I propose breaking up the Library class into separate services focused more on independent responsibilities.

LibraryNamespaceResolver (patternkit.library.namespace_resolver)

This service addresses the responsibility of mapping library namespaces to the providing extensions and their library definitions. To achieve this, it builds on top of the already assembled and altered library discovery information provided by Core via the @library.discovery service. This offloads much of the work for considering how other assets are handled in libraries that our module doesn't care about and lets our service focus on processing and capturing the pattern collection data at the library definition level before it is processed and individual patterns are discovered.

Once the library data is prepared with the inclusion of pattern-specific collection data, this service is responsible for caching this information.

PatternDiscovery (patternkit.pattern.discovery)

This service serves as the entry point for most developer needs to work with discovered pattern definitions. Through this service, the developer has access to retrieve pattern definitions that have been discovered, whether that be a specific pattern, all patterns within a given namespace, or all patterns that have been discovered across all namespaces. Behind the scenes, the PatternDiscoveryCollector service is used to discover and cache these pattern definitions.

PatternDiscoveryCollector (patternkit.pattern.discovery.collector)

This service is the driver for leveraging the pattern library data assembled in the LibraryNamespaceResolver and feeding it to the existing PatternLibraryParser services in order to discover available patterns. These discovered patterns are then cached for access via the PatternDiscovery service.

Remaining tasks

User interface changes

None

API changes

• See new services introduced above.
• Usage of the Library (patternkit.asset.library) service is deprecated and marked for removal in the 1.0 release.
• Pattern definitions should now be loaded through the patternkit.pattern.discovery service.
• The "Use Patternkit Library Cache" option temporarily has no affect until follow-up work is completed.

Data model changes