Add a polyfill module for things that are coming to core

Linking some core issues that I think we could polyfill.

This module would have very narrow compatibility with core -- each minor version would only support a specific minor of core (i.e., core_version_constraint: ~11.2.0).

In slack recently I demonstrated how difficult s3fs's versioning policy makes it to update core when both are behind a minor release, and how bad composer's feedback is when you try to find out what's preventing an update. This would I think be even more difficult for end users than s3fs.

Or to put it differently:

If you're on Drupal 11.2 and you want to update to 11.3 which composer update command will work? Which composer commands that you expect to work will stop working with this module installed? Can automatic updates execute the ones that will work and what happens in the failure case?

And apart from that, package manager is still experimental so the things above can probably be backported to patch releases which are every month. Is one month too long to wait? Is the idea to reimplement all this code in Drupal CMS before they're committed? But then are you going to handle upgrade paths for config changes on top?

package manager is still experimental so the things above can probably be backported to patch releases which are every month

A month isn't too long to wait, if those things are backportable. 😎

But I'm leaving this issue open for when this arises again. I hear you on the update front, and agree that we should do what we can to avoid Composer's weird update gridlock due to ~ constraints for core.

Created the project: http://drupal.org/project/drupal_cms_helper

The initial implementation will most likely be added in ✨ Require Drupal 11.2.3 and add Composer as a runtime dependency Postponed , and won't have a narrow core constraint, precisely to prevent update pain.