Depend on Composer

Update

This project was moved to https://www.drupal.org/project/backport, see comments in this issue and #2947630: Transfer ownership of Backport module.

Problem/Motivation

Ok, hear me out.

Things have changed a lot in the Drupal ecosystem since this module was initially created and since @Fabianx's original feelings towards this topic (#2513036-1: Remove Dependencies (Symfony & Drupal Components) from the repository).

Drupal 8 itself even made Composer "official" in #1475510: Remove external dependencies from the core repo and let Composer manage the dependencies instead.

I think it's quite safe to make the judgment that Composer is now "de facto".

https://www.drupal.org/docs/develop/using-composer
https://www.drupal.org/docs/develop/using-composer/using-composer-with-d...

Drupal.org has also made leaps and bounds in regards to infrastructure and packaging over the years:
#2551607: [meta] Path forward for Composer support
#2485011: Infrastructure Requirements to support Composer based workflows
#2352091: Create (and maintain) a subtree split of Drupal core
#2513388: Create (and maintain) a subtree split of each Drupal Component

---

It was also brought up in #2513036: Remove Dependencies (Symfony & Drupal Components) from the repository that this module bundles external 3rd party code (where licensing isn't exactly 100% compatible). Given the advent of the core/component sub-tree split, I think it stands to reason that it would be far easier to simply depend on Composer Manager.

Drupal 7 has no "native" support for Composer like Drupal 8 does and we'll need something that we can, reliably, use to retrieve Composer's autoloader.

Then this module can simply require drupal/core so we can have the full heart of Drupal 8 at our fingertips, but only hook up the parts that can be supported in Drupal 7.

This means we'd likely need to create a Drupal 7 specific DrupalKernel and our own supported core.services.yml that allows us to "bootstrap" Drupal 8 code within the confines of Drupal 7.

Whenever we need to replace or "fix" something for Drupal 7, we can extend or replace services as needed.

For classes that aren't services (e.g. Drupal\Core\Site\Settings), we can use cweagans/composer-patches to patch them as needed.

Think of this as kind of like running "Drupal 8" within Drupal 7, but where Drupal 8 is using Drupal 7's DB and methodology when it has to.

The performance impact is quite negligible once the container has been fully built since most of Drupal 8 code is autoloaded classes. Given that most of the code in Drupal 7 is procedural (including most Drupal 7 contrib), the relatively "weight" of doing this is rather minuscule.

Things like routes and rendering, for example, will likely never be able to be supplemented given the vast difference between the versions.

The three primary reasons I'm suggesting any of this is because:

1. It will make maintaining this module much easier.
2. This module isn't duplicating code that already exists.
3. It will give sites a way to preemptively "upgrade" their site in pieces before actually doing a real full upgrade (think d.o, which is currently on Drupal 7).

---

Also, I know I just created the 7.x-2.x branch, but I'm begnning to think this module should actually move to major versioning parity with each Drupal 8 major version, e.g.:

7.x-4.x === 8.4.x
7.x-5.x === 8.5.x
7.x-6.x === 8.6.x

Proposed resolution

• Create a new 7.x-4.x branch
• Add any composer dependency
• Refactor module's composer.json to require drupal/core: ~8.4.5
• Remove unnecessary code
• Create Drupal 7 specific DrupalKernel
• Create Drupal 7 specific core.services.yml
• Start hooking up services that can be backported.

Remaining tasks

• Discuss and garner information that allows us to come to a dicision
• Create POC
• Create child issues

User interface changes

TBD, but likely none

API changes

TBD, but some are likely

Data model changes

TBD