Extension packages are unmaintained or don't support latest features

[Oleksandr Prypkhan]

This is a follow up of #529.

Currently there are additional "optional" packages that graphqlite provides: graphqlite-misc-types, graphqlite-laravel and graphqlite-bundle, graphqlite-symfony-validator-bridge. There are also some integrations that are built right into graphqlite itself with class_exists() checks, like with MyCLabs enums or Porpaginas & LengthAwarePaginator.

There are three approaches projects take:

1. manually maintaining optional extensions - like graphqlite mostly does
2. automatically subtree the project into sub-packages - like Laravel/Symfony does
3. monorepo with all of the optional dependencies being just that - composer "suggested" dependencies with checks for interface/class existence - like graphqlite partly does

The problem with the first approach, one graphqlite mostly takes, is that it requires a lot of efforts to be maintained properly. At this moment:

• graphqlite-misc-types is practically unmaintained and doesn't work with the latest versions of graphqlite
• graphqlite-symfony-validator-bridge - it doesn't use the "latest and greatest" input type validator interface, nor does it support attributes
• graphqlite-laravel is incompatible with graphqlite 6.1.0 due to lots of breaking changes. Also, for some reason LengthAwarePaginator of Laravel is mapped by graphqlite itself, not by graphqlite-laravel

All of these can be fixed, but it's very likely that this will happen again and again.

There's one option to take that can simplify all of this: a monorepo with optional dependencies. It doesn't sound as nice as independent extension packages, but it brings a lot of benefits to projects like graphqlite which don't have many human resources to spare:

• it makes it easy to support all the first-party packages. Given tests are written, there will no longer be situations where extension packages suddenly break or don't support the latest features
• it makes it easy to version & release because there's only one package and one version to keep track of
• it makes it easier to write internal, non public-API abstractions like the case of Paginator - right now both supported paginators share the same type mapper; instead of creating a separate "paginator adapter" public API that would allow graphqlite-laravel to define how to map LengthAwarePaginator, graphqlite could instead do the same but internally, without exposing any public API

Inside of the monorepo (i.e. this repo), it can then be split by context:

src/
├─ Symfony/
│  ├─ SymfonyInputTypeValidator.php
├─ Core/
│  ├─ TypeHandler.php
├─ Laravel/
│  ├─ GraphQLiteServiceProvider.php

This isn't ideal from an architecture standpoint, but it's good enough when there isn't enough manpower to handle all of these packages. What do you think?

[Jacob Thomason]

So, we've had this discussion a few times across various issues. I have zero interest in maintaining or working on any of these plugin packages. Firstly, we use GraphQLite within a fully custom "framework", so none of these are of value, personally. But also, I don't have a lot of experience with or other means of assisting.

I agree that a mono-repo on these would be ideal, if it's in the best interest to actually maintain these things. I think if people are finding value in them though, they should step up and offer to maintain them.

Personally, I feel like this repo needs to entirely evolve on it's own without consideration for these other packages. Bringing them into a mono-repo is only going to add dependency concerns when making design decisions on what's best for GraphQLite. I don't think it's the best interest of this repo.

• graphqlite-misc-types should probably be archived and any valuable documentation rolled into the main docs
• MyCLabs is deprecated and will be removed soon in favor of native enums.
• Porpaginas & LengthAwarePaginator - we should use interfaces where possible and adapters. But we shouldn't rule out 3rd party deps.

[Oleksandr Prypkhan]

I see; that makes sense. What about three other complementary packages? -bundle, -laravel and -symfony-validator?

We're using Laravel but we also need support for Symfony validator, Carbon, other scalar types so we're better off maintaining our own big extension package instead and backporting features into graphqlite where possible.

Should those repos be archived then?

[Jacob Thomason]

Are you interested in maintaining these other packages? There are quite a number of people using them. I agree they're not the most up to date. That comes down to having someone maintain them, and aside from me pushing through some PRs here and there, there isn't much else happening. Granted, there isn't a lot that needs to happen with them anyway. They're mostly adapter packages.

[Oleksandr Prypkhan]

Unfortunately no :( As I said we'd be maintaining our own package and to keep things simple, I'd rather maintain one than three.

[Jacob Thomason]

Totally understandable. We'd probably do the same, which is why I don't see a lot of value in them. I guess they're great for people wanting to spin something up quick without much understanding for how everything works.

[Francesco Laffi]

Could be interested in helping on the symfony related packages, what would you think could be the best way?

• fork and maintain on different namespace, if its not interesting to maintain as an official package
• send PRs, that someone has to actually review and bring forward with releases
• ask to be added as maintainer for the packages

[Jacob Thomason]

@francescolaffi create an issue ticket over there. I'm a maintainer, but not sure if I have permissions to add other maintainers. We can discuss further.

[asrar]

I think the integration with laravel and symfony could be maintained inline with the core package, a mono repo certainly makes that easier.

My assumption is most users of this package are using it indirectly via framework plugins, so merging them here brings more dev attention to this package, making maintenance easier in the long run.

[Oleksandr Prypkhan]

@aszenz Not maintaining them at all is even easier :)

[asrar]

@aszenz Not maintaining them at all is even easier :)

In the short term yes, in the long term graphqlite may become less used without up to date framework integration and stay as a niche package which means less people interested in maintenance

[Jacob Thomason]

@aszenz the issue is that I don't use either, and have no way of testing or ensuring that these packages are working properly. You make a good point, but maintaining compatibility with these is difficult in this package and only holds back development on the actual core.

If someone else wants to step up as a maintainer of this package and the extensions, that's something we can discuss further. But, I don't think considerations around implementation should be made within this core repo, regardless. At present, it's more likely that they'll just break with updates.