‼️Upcoming 9.0.0 release will have multiple breaking changes‼️

[mfn]

👋🏼

• the upgrade to graphql-php 15 brings upstream breaking changes
  => ❗BREAKING CHANGE❗️Ensure compatibility with graphql-php v15 #953
• removing GraphQL type eager loading (i.e. removing support for non-lazy loaded types) removes some weird things we had in the code base, especially tests, and I think it's time to get rid of it and just always use a type loader
  => ❗BREAKING CHANGE❗️ Remove optional support for non-lazy loading of types #966
• say goodbye to Laravel 6. With L10 around the corner, I think it's about time.
  => ❗BREAKING CHANGE❗️Remove support for Laravel 6 #967
• Remove integrated GraphiQL support in favour of https://github.com/mll-lab/laravel-graphiql
  => ❗BREAKING CHANGE❗️ Remove GraphiQL integration #986

The graphql-php upgrade exposed some very strange type resolve errors with the eager/lazy loading I could not resolve in hours of time, so I decided to solve this the other way around and get rid of the global flag.

This further motivated me to look and realize that L6 is out of security updates and most library already removed support for it; and given that L10 was around, I'm thinking this is justified.

My current plan is to make the current 8.5.0 release the latest 8.x branch and merge all the above PRs into master and release RC1.

8.x won't be maintained after the 9.0.0 release, but I'll keep a respective branch around for a while for urgent hotfixes.

I plan to release 9.0.0 more or less "now", but let's see the feedback/arguments here! Also if you have other ideas for breaking changes, now is probably a good time 😄

cheers

[tm1000]

Was just going to ask about this in issues! Glad I looked here instead!!

[tm1000]

I noticed that webonyx now supports standard php enums, https://webonyx.github.io/graphql-php/type-definitions/enums/#construction-from-php-enum

Is there a thought for how this library will implement them or would it be best to use just the webonyx methods. What I mean by this is that right now Enums extend Rebing\GraphQL\Support which extends GraphQL\Type\Definition\Type.

[mfn]

Good question, basic answer: I've no idea (yet).

Sadly for me, PHP 7.4 is still the base line on most projects I work and all of this looks like to be PHP 8+ exclusively.

This was kind of the technical answer. The philosophical answer would be that I see graphql-laravel as a thin and transparent layer between the two libraries, therefore: the less specific code it would need to make it work, the better (IMHO).

thin and transparent

I think this is also evident by many of the things from graphql-php showing through.

[tm1000]

https://github.com/rebing/graphql-laravel/tree/mp-graphql-php-v15

[mfn]

I've just added another item to the BC / removal list:

• Remove integrated GraphiQL support in favour of https://github.com/mll-lab/laravel-graphiql
  => ❗BREAKING CHANGE❗️ Remove GraphiQL integration #986

The integration is definitely very convenient, but the way it's integrated it's hard to maintain.

I always favoured a "source local" solution, that's why I kept it so loing.

But https://github.com/mll-lab/laravel-graphiql , whilst defaulting to load remote resources, also allows them to download locally; which I believe is great approach.

[mfn]

I've pushed out all the announced changes as 9.0.0-rc1, please head over to #998 for any feedback from here on, thank you 🙏🏼