Moving Gin from contrib to core: namespace considerations

Ideally it should have a different name in core. That would avoid the possibility of issues.

We do have some functionality for this on git.drupalcode.org, a dependency on any core component is interpreted as a dependency on core. (Composer does not have a concept of components, sub-themes, sub-modules, those are Drupalisms.) So this may “just work,” although someone running a version of core without gin may need to explicitly require gin if they are starting by requiring something that depends on gin.

Thank you @drumm for your feedback.

Changing the name wouldn't be our preferred solution.

So, if the name remains the same, and it lives in Drupal core as of 11.3, it will be packaged and distributed as part of core for that version and beyond. But what happens to those who use older versions of core and if they call composer require drupal/gin, directly or indirectly. Do they even get a chance to receive the existing Gin versions from contrib, which may still receive patch releases or some time?

I'm reading #2 such that it may work, but we don't know for sure. If I'm reading that correctly, do have any options to give it a try? Also, from that same comment it sounds like if contrib Gin were a dependency of something else, it would still have to be required directly in order to work?

One possible way to handle this:

1. Continue to point packagist to contrib gin for drupal/gin

2. Contrib gin releases a new branch for >= 11.3 that has only a README in it - this way the core theme will be used on all 11.3 sites.

3. (possibly) core should specify provides or replaces for drupal/gin in 11.3 so that composer assumes it's already there.

I think this would mean that sites updating to 11.3 would be automatically switched over to the core version of the theme.

It would make it very difficult for sites to install contrib gin on 11.3 but that might be a 'feature' and/or we could document how to do it.

If core uses the composer.json replace property to say that core now includes Gin, and the facade continues to point to the contrib version, will that work? Existing versions of core will not see any difference, newer versions of core will tell Composer that they already include Gin so the contrib version is not required?

Yeah I think #5 might be enough - this ought to be testable locally since it affects composer's local behaviour rather than packagist (I think?).

I think everything in Composer is testable locally with path repos, the tricky part is setting it all up correctly to match what would actually happen with packages.drupal.org.