jlevers / selling-partner-api

A PHP client library for Amazon's Selling Partner API

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot update PHPOffice/PhpSpreadsheet

leopado opened this issue · comments

In your compser.json there's a dependency from PHPOffice/PhpSpreadsheet but it is fixed to a single version 1.25.2
So it's impossible to update this package even for minor version o bug fixes (actually phpspreadsheet is at version 1.29).
Are there any backward to change the composer.json with ^1.25.2 so the minimum version required is 1.25.2 but minor or fixes updates can be acceppted by composer update.

Thank you.

Best regards

@jlevers any news about this issue?

Thank you.

Best regards

Just to follow up on our project fixing to version 1.25.2 has a cascade effect on some other libraries including maennchen/zipstream-php and psr/http-message causing them all to be downloaded. Any chance this can be fixed? Thanks.

Any new about this one? Still stuck too because of this restriction.
Could we have at least an answer?

Just FYI I got round this by adding the following into my composer.json All working fine.

"phpoffice/phpspreadsheet": "1.29.0 as 1.25.2",

@stevenbrookes thank you for your workaround. I will do like you, hoping it will change directly in this library after.

Sorry for the radio silence...if you upgrade to v6, PHPSpreadsheet is removed altogether. It was locked to a particular version to maintain backwards compatibility with PHP 7.3, but v6 has a minimum PHP version of 8.1, so the whole set of issues that came along with supporting an old PHP version are now gone.

@jlevers great news I'll take a look at that.

I saw you used saloon-sdk-generator to create the SDK etc. Can I ask why you used that library? We've been using openapi-generator for a while and we are looking for something that generates more modern and flexible code. We've looked at janephp (https://github.com/janephp/janephp) but not yet taken the plunge. I'd be interested in your thoughts.

I went through a few different codegen systems before settling on this one.

  • A custom openapi-generator generator. I didn't get very far before deciding that a) it wasn't configurable enough without a ton of work, and b) I didn't want to maintain a PHP library in Java.
  • janephp, which had some promise, but I found it hard to configure, and it wasn't quite as flexible as I had hoped. It's totally possible that I just didn't spend long enough on it, so I wouldn't write it off based on my experience, but I wanted something more light-weight, and with more ability to override features I didn't like or wanted to change.
  • I came across Saloon, which I really like. It doesn't impose more structure than necessary, while also making it easy to handle things like multiple forms of authentication (necessary for the SP API), middleware, data validation, etc. It also makes it easy for the user to debug requests, get raw requests/responses, and generally customize their experience, which I felt was missing from this library till now.

I started writing my own Saloon generator from scratch, and then came across crescat-io/saloon-sdk-generator. At the time, it didn't have support for body schema/response/DTO generation, so I forked it and wrote that part. It looks like they've since added support for basic body schemas and DTOs, although I think that my fork is still ahead in terms of full OpenAPI spec compatibility. That said, I haven't maintained the Postman schema generation side of things in my fork, so I'm sure they're ahead of me on that. I should talk with them about merging my fork somehow.

Hope that helps :)

Thanks that's very helpful. I'll give both fork's a try. Does sound like it would be good to feedback to the original project - sometimes too much choice isn't a benefit! Oh and thanks again for this library - a real time saver.