5.0 idea: eliminate the submodule?

I was thinking about starting a 5.x branch just so we don’t forget to prune our deprecations, but I kinda want a better reason. There’s no point in marking the beginning of that path if we aren’t going to walk down it. I know we have several ideas of cool things to add, but (afaik) none of them has a real use case, so we don’t actually need to go anywhere. Most of the cool ideas could be added to 4.x just fine; additions rarely need to eliminate existing stuff.

Then I had an idea that would definitely break things: we don’t need saml_sp_drupal_login.

Option: what if we consolidated it into the main module?

I get that, conceptually, being a SAML service provider is a different set of operations than establishing a Drupal session. Theoretically someone could write their own whatever_drupal_login module and use that instead.

But I’m pretty sure nobody is doing that. And we definitely haven’t documented the API to make it easy for them if they wanted to. So we’re carrying around a bunch of extra complexity that doesn’t benefit anyone.

Advantage: our code would be easier to maintain. If nothing else we can restructure the controllers so each one isn’t the only thing that calls code in the other module.

Disadvantage: this would be a royal pain to implement.

Right now I don’t see any ideas for functionality that would make this change necessary; it’s really just a huge, complicated code cleanup task. But if we’re ever going to do it, it won’t be any less complicated in the future.

Option: what if we replace it with ExternalAuth → ?

This is hard to think about because we’ve put a lot of effort into developing and maintaining our own implementation of what that module provides, and it feels like throwing all that time away.

There’s a reason the sunk-cost fallacy is called a fallacy. We did what we needed at the time, because ExternalAuth wasn’t available, now we don’t need to keep doing it.

In the age of Composer-managed dependencies, not relying on any other Drupal modules isn’t really a selling point, is it?

Advantage: our code would be easier to maintain.

Disadvantage: this would also be a royal pain to implement, but probably less than consolidating.

I don’t have a strong feeling about either of these, but I wanted to start the discussion anyway. It’s a good idea to deliberately revisit this early structural decision as we approach Drupal 7 EOL — even if we don’t change, we can do so having considered all the options in the current landscape.