Needless dependency on symfony/yaml

[mieszkomalawski]

trafficstars

Hi,

Related to https://github.com/lezhnev74/openapi-psr7-validator/issues/65 and idea of moving this package to php league.

I personally believe that in order to spread good practices and allow as many folks as possible to use openapi validation, we should focus on having as little dependencies as possible.

Currently, this package uses cebe/php-openapi which forces installation of symfony/yaml component. This indirectly forces a minimal version of Symfony (version >=4 I believe) and cuts off some potential developers. IMO input source (json/yaml) should be separated from parsing library. It should be up to developer to parse yaml/json (symfony/yaml could be a suggestion in composer.json) and then pass array or stdClass to cebe/php-openapi. This may seem like a bit of extra effort from developer but it will result in less dependencies and higher adoption.

[scaytrase]

Or we can improve cebe/php-openapi to work with all not eoled yaml versions, which is not so hard to do

вс, 8 сент. 2019 г., 10:58 Mieszko Malawski [email protected]:

Hi,

Related to #65 https://github.com/lezhnev74/openapi-psr7-validator/issues/65 and idea of moving this package to php league.

I personally believe that in order to spread good practices and allow as many folks as possible to use openapi validation, we should focus on having as little dependencies as possible.

Currently, this package uses cebe/php-openapi which forces installation of symfony/yaml component. This indirectly forces a minimal version of Symfony and cuts off some potential developers. IMO input source (json/yaml) should be separated from parsing library. It should be up to developer to parse yaml/json (symfony/yaml could be a suggestion in composer.json) and then pass array or stdClass to cebe/php-openapi. This may seem like a bit of extra effort from developer but it will result in less dependencies and higher adoption.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lezhnev74/openapi-psr7-validator/issues/67?email_source=notifications&email_token=ABSGB3J4GWKPDNVQVJAMANLQISWEBA5CNFSM4IUSSTGKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HJ73FIQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSGB3IXGNS2I6T23IJS3Z3QISWEBANCNFSM4IUSSTGA .

[lezhnev74]

pinging @cebe

btw, speaking of dependencies. The open PR #64 adds dependency to https://github.com/dflydev/dflydev-fig-cookies which does PSR-7 cookies parsing. Do you think it is excessively?

What would be a go-to strategy to pick which dependencies are allowed and which are better not?

p.s. Another question which remains, what php version we want to support? If #64 gets merged that min requirements move to php 7.2+ instead of 7.1+

[mieszkomalawski]

dflydev/fig-cookies itself does not have many dependencies so I guess it's fine.

Looking at these stats https://blog.packagist.com/php-versions-stats-2019-1-edition/ about 65% people use 7.2 or above. Still 15% folks using 7.1 would be cut off. I would try to still support 7.1 if it's possible but if it means that some important feature will be blocked then I would consider abandoning 7.1

[digilist]

PHP 7.1 reaches end of line in 2 months and will not receive any security updates anymore (see https://www.php.net/supported-versions.php), so anybody who is still running 7.1 needs to update urgently.

Imho, PHP 7.1 should only be supported if it does not block any feature development (and also does not complicate it). In all other cases people need to upgrade their PHP version first to use new features.