We've implemented omnipay as v3 about 2 years ago now, and it works fine for the most part.
I was wondering if you were considering a new major version which would require a rework?
Things to consider:
The base Omnipay http client implementation uses a custom http client interface It would be entirely possible to simply move to PSR-18 along with http client discovery, and http-message-factory interfaces, thus allowing any framework to simply plug in an implementation, and dropping guzzle as a requirement.
This is a breaking change, as the client requirements would change along with the exceptions thrown.
I would propose also no default client to be added, instead by going along with what composer wants us to do simply require an implementation.
This would allow omnipay to completely decouple from http requests.
The gateways are created statically and sit in a "main" namespace, with logic that will create objects in a rather strange way
This should likely be just removed, instead the gateways should implement a main interface and sit in separate namespaces.
A "shared" main namespace could still be considered for official gateways.
The methods for gateways could be split into interfaces instead of an annotation, thus having a proper requirement of implementation on the gateway and allow someone to simply do a $gateway instanceof PurchaseGatewayInterface
No more setters/getters into infinity that are a hard requirement
By requiring php 8.1 or simply moving some of the logic elsewhere it would be possible to stop using the set/get pattern along with likely dropping the requirement for ParameterBag and by thus I believe the symfony-framework?
If still needed it would be wise to maybe consider an alternative, or simply store parameters in an array.
There's little to any input validation
I'm currently on implementing another gateway for our project and I noticed that barely anything typechecks, as omnipay was designed to work with... php5?
Updating language features
At a time like this it seems a good idea to jump straight to php8.1 allowing a greater freedom of choice and improving development experience. The project could also use an upgrade of all libraries in use (omnipay/tests still uses phpunit 6...)
Updating quality tools, ensuring templates and so on
As code evolves it would be a good idea to use phpstan, psalm and so on as quality assurance tools.
Hello.
We've implemented omnipay as v3 about 2 years ago now, and it works fine for the most part. I was wondering if you were considering a new major version which would require a rework?
Things to consider:
This is a breaking change, as the client requirements would change along with the exceptions thrown. I would propose also no default client to be added, instead by going along with what composer wants us to do simply require an implementation. This would allow omnipay to completely decouple from http requests.
This should likely be just removed, instead the gateways should implement a main interface and sit in separate namespaces. A "shared" main namespace could still be considered for official gateways.
The methods for gateways could be split into interfaces instead of an annotation, thus having a proper requirement of implementation on the gateway and allow someone to simply do a
$gateway instanceof PurchaseGatewayInterfaceBy requiring php 8.1 or simply moving some of the logic elsewhere it would be possible to stop using the set/get pattern along with likely dropping the requirement for ParameterBag and by thus I believe the symfony-framework? If still needed it would be wise to maybe consider an alternative, or simply store parameters in an array.
I'm currently on implementing another gateway for our project and I noticed that barely anything typechecks, as omnipay was designed to work with... php5?
At a time like this it seems a good idea to jump straight to php8.1 allowing a greater freedom of choice and improving development experience. The project could also use an upgrade of all libraries in use (omnipay/tests still uses phpunit 6...)
As code evolves it would be a good idea to use phpstan, psalm and so on as quality assurance tools.