Introducing a Plugin API

[mackoj]

Following up on our previous discussion here, this PR introduces a core mechanism for adding and registering plugins. This foundational work sets the stage for developing more advanced and powerful plugin APIs in the future(like #906).

Plugin API for swift-snapshot-testing

This PR introduces a Plugin API architecture that enables greater flexibility and extensibility, it addresses the need for shared functionality across different snapshot strategies.

Why a Plugin API?

The feedback from @mbrandonw and @stephencelis highlights two main concerns:

1. Breaking changes: The proposed changes would be breaking, requiring a major version bump to 2.0.
2. Modularity: There's a desire to minimize changes to existing strategies and focus on a plugin-izable future for a potential 2.0 release.

This PR directly aligns with those concerns by introducing a modular, forward-looking Plugin API that would allow users to extend snapshot functionality in a non-invasive way. This architecture is designed to be compatible with future versions, helping the library move toward a more flexible and scalable ecosystem without requiring breaking changes in each strategy.

Key Benefits of the Plugin API

1. No Breaking Changes: This implementation is backwards-compatible, ensuring that existing users are unaffected. It introduces an optional, extensible plugin system that users can opt into, avoiding disruptions for those who don't need it.

2. Modularity: Plugins allow new functionality to be added without changing the core snapshot strategies. This decoupling keeps the core library simple, while allowing third-party developers to introduce and share new functionality through plugins.

3. Extensibility: The Plugin API provides a formal structure for shared behaviours across different strategies (e.g., image formats, file storage) without needing to duplicate or modify each strategy. This approach encourages a vibrant ecosystem where developers can contribute plugins for specific use cases.

4. Future-Proof: Introducing the Plugin API now lays the groundwork for future versions of swift-snapshot-testing, aligning with the long-term vision for a more plugin-izable system (as mentioned by @stephencelis). The architecture is designed to evolve and adapt, providing flexibility for whatever comes next in 2.0.

Technical Overview

• SnapshotTestingPlugin: Defines the behavior that plugins must implement.
• PluginRegistry: A singleton that manages dynamic plugin discovery and registration, utilizing the Objective-C runtime to automatically register plugins conforming to the SnapshotTestingPlugin protocol.
• Objective-C Runtime Integration: Allows automatic discovery of plugins that conform to specific protocols, ensuring extensibility without manual intervention.

Next Steps

Although the core team is considering a more modular approach for 2.0, this PR serves as an incremental step in that direction. Rather than requiring a full 2.0 release immediately, the Plugin API can be introduced now as an optional feature that sets the stage for future developments.

Conclusion

I hope this Plugin API proposal is a step forward in making swift-snapshot-testing more flexible, extensible, and future-ready without disrupting current users. I'd love to work with the team to refine this proposal, and I’m open to any suggestions for improving or adapting the architecture to better align with your vision.

Plugins

• Image Serialization Plugin: This is the first plugin that utilizes the new Plugin API.

• Another potential plugin could be one that changes where snapshots are saved. This could include options such as local storage (the default), FTP, SFTP, S3, Dropbox, Google Drive, and more. Implementing such a plugin would enable easy integration of various storage solutions for snapshots. (🤔 should I build this next?)

These examples demonstrate the utility of this API.