Add a polyfill module for things that are coming to core

Created on 6 July 2025, 1 day ago

Problem/Motivation

Core evolves more slowly than Drupal CMS. This is well and good, but there are sometimes improvements that would confer outsized benefit to Drupal CMS if they were introduced sooner rather than later. It sucks to have to wait for up to 6 months to get pretty solid core improvements into Drupal CMS.

Proposed resolution

Why don't we create a shim module? Just one, called drupal_cms_helper. This would be a normal module, part of our subtree split. Drupal CMS could bring it in as a dependency like any other module.

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). Its job would be to polyfill functionality that has already landed in core, but merely hasn't been released yet. Not every core improvement will be polyfillable in this way, but a quite a bit will be -- for example, the friction-reducing improvements in Package Manager that I'm currently trying to push into core. The helper module can be as thin or as maximalist as we need, and it would give us some latitude to deliver helpful features to our end users faster.

The helper module would emphatically NOT be used to fix bugs in upstream dependencies. Only to "release" features earlier than they otherwise would be.

πŸ› Bug report
Status

Active

Component

General

Created by

πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @phenaproxima
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    Linking some core issues that I think we could polyfill.

  • πŸ‡¬πŸ‡§United Kingdom catch

    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?

  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    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.

Production build 0.71.5 2024