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

Cannot update PHPOffice/PhpSpreadsheet #617

Closed
leopado opened this issue Sep 14, 2023 · 9 comments
Closed

Cannot update PHPOffice/PhpSpreadsheet #617

leopado opened this issue Sep 14, 2023 · 9 comments

Comments

@leopado
Copy link

leopado commented Sep 14, 2023

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

@leopado
Copy link
Author

leopado commented Jan 12, 2024

@jlevers any news about this issue?

Thank you.

Best regards

@stevenbrookes
Copy link

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.

@MickDev13
Copy link

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

@stevenbrookes
Copy link

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",

@MickDev13
Copy link

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

@jlevers
Copy link
Owner

jlevers commented Mar 22, 2024

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 jlevers closed this as completed Mar 22, 2024
@stevenbrookes
Copy link

@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.

@jlevers
Copy link
Owner

jlevers commented Mar 22, 2024

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 :)

@stevenbrookes
Copy link

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.

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

No branches or pull requests

4 participants