Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introducing a Plugin API #905

Closed
wants to merge 1 commit into from
Closed

Conversation

mackoj
Copy link
Contributor

@mackoj mackoj commented Sep 14, 2024

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? prototype implementation not finished)

These examples demonstrate the utility of this API.

@mackoj mackoj changed the title Add only the PluginAPI Introducing a Plugin API Sep 14, 2024
@mackoj mackoj mentioned this pull request Sep 14, 2024
4 tasks
@mackoj mackoj marked this pull request as ready for review September 15, 2024 00:00
@mackoj mackoj force-pushed the faet/pluginAPI branch 6 times, most recently from a3eab77 to a793448 Compare September 16, 2024 21:09
@mackoj
Copy link
Contributor Author

mackoj commented Oct 4, 2024

The automatic registration require Objective-C runtime and is optional if need we can use the registerPlugin that works on platform that don't have obj-c runtime.

@mackoj
Copy link
Contributor Author

mackoj commented Oct 6, 2024

The code here exist inside #906 anyways so let's close this.

@mackoj mackoj closed this Oct 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants