Change Travis to GA + possible CS changes?

[LordSimal]

Hey there 😄

I was just going to ask if you are interested in converting the CI for this repo from Travis to Github Actions. Github Actions provide all the things you need in here so I would gladly help you convert that.

---

The other thing also related to CI is your current choice of php-cs-fixer. I am not really a fan of that module because there is no easy way to

• show "wrong" files and what exactly is wrong inside those files
• integrage that in Github Actions to make CI work with that as well (at least as far as I know)

So related to the Travis => GA change I would also recommend https://github.com/squizlabs/PHP_CodeSniffer We in the CakePHP core team use it in CakePHP + all related plugins as well and we love it 😄

If that would be OK for you the main thing here is what kind of CS-Ruleset you like to use. As I currently see this repo uses something based upon symfony but just wanted to ask what you say about that before going any deeper 😄

[jeromegamez]

Hi 👋🏻!

it's a good idea to go with GitHub Actions, I'll migrate this today - since I have a few other projects already using them, it won't take long 🤞🏻. I haven't done so yet because the library is stable, but it would be good house keeping, so I'll be happy to do it.

Concerning the code style and PHP CS Fixer: as you said, it's my choice, so I'll stay with it 😅. The rules are super simple and are handled by capable IDEs out of the box; and if you only use the library, it shouldn't make much of a difference anyway...

However! If you plan to work on the library, feel free to fork/copy it and make changes as you like - in that case I would keep everything as it is, archive the repo, mark it as abandoned on Packagist and suggest your fork as a replacement.

Let me know which route you'd prefer!

[LordSimal]

The CS thing is just something I am used to so its nothing major I want to push onto here 😄

I haven't tested this lib with PHP 8.2 yet but I guess it won't be a major problem. But currently there is no easy way to test that since there are no tests present 😅 Maybe thats something I can provide along the way.

So thanks for the offer, maybe in the future 😉

[jeromegamez]

Concerning the tests: we (sadly, because I love mite) don't use mite at my workplace anymore, so I currently can't add integration tests although I would like to.

A GitHub sponsorship of >= 10€/$ 😇 would allow me to create an account with one admin and one regular user - alternatively I would be grateful if perhaps @yolk could provide me with an account 🙈. That would also allow me to safely bring the library to the next level (think, for example, proper value objects).

I'm also planning to migrate/recreate the project in the beste organization to detach it from the Gamez namespace and re-publish it as beste/mite, which has a nicer ring to it 🎶.

But for now I'm concentrating on a 3.0 release with the current feature set here 💪🏻.

[yolk]

Please get it touch (https://mite.de/en/imprint.html) and we can provide you with a free developer account.

[jeromegamez]

@LordSimal If you'd like, have a look at the 3.x branch

# In a new folder
composer require kriswallsmith/buzz nyholm/psr7 "gamez/mite:3.x-dev"
# In an existing project
composer require "gamez/mite:3.x-dev"

I'm confident it works so far (I had a small manual test run thanks to the amazing people at @yolk), so, if I don't hear back from you, I'll release Version 3.0 this evening and start with the reboot in the BESTE organization 💪.

Tests via GitHub actions are also in place, so I'm going to close the issue now since it's basically done, but feel free to add further comment(s) if I missed a bug. Thanks!

[LordSimal]

Thanks @jeromegamez, I just looked at the compare view from 2.x <- 3.x and there isn't much that should create problems so thanks for that 🙇🏻 The only thing I wanted to mention is, that by no tests present i mean no PHPUnit tests like unit tests, integration tests etc. inside a tests folder so one can check via (usually) mocked API responses that everything works as expected.

PHPStan itself isn't really testing if the code works as designed but just does static code analysis like variable and parameter types match as expected and there is no "dead code" present. So that is just something I would recommend for the new reboot in the BESTE organistion to take into consideration 😉

[jeromegamez]

My approach is to not unit-test what I don't own... sure, I could mock all API responses, but that's a lot of overhead, and once the API response changes, unit tests still pass. Integration tests would fail, but then I'd have to update the mocked responses, just to align them with what the integration tests already test.

So far, the library is simple enough - it just returns 1:1 what's documented in the official docs, that's why I didn't bother to add tests; once I rewrite the library, you can be sure to find a tests folder 😅, especially now that I can indeed add integration tests thanks to the developer account 💪🏻

[LordSimal]

well my thinking is that I don't want to bombard an API with HTTP calls everytime I want to run my tests. Sure, with mocked responses I don't know if the real API changes but if that so happens from one day to the other then the API publishers have made a big mistake anyway since they probably broke hundrets if not thousands of applications reliant on it. Anyway, its just my opinion, you do you and I am happy that this library gets support and will be supported in the future 👍🏻