Non-installable dependencies due to non-updated modules

[jekuaitk]

Leniency

Currently, we use Drupal composer lenient to allow installation of two¹ non-updated modules:

• Webform node element
• Webform auto exports¹

While this has allowed us to keep on going as normal in already started projects, it comes with the issue that new drupal 10 (or 11) projects that require os2forms cannot be installed from scratch without work-arounds.

Example

A simple composer.json like the following

{
    "require": {
        "drupal/core": "^10.3 || ^11.0",
        "os2forms/os2forms": "^3.6 || ^4.0 || ^5.0"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "minimum-stability": "dev",
    "prefer-stable": true
}

Will report the following during a composer install:

Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires os2forms/os2forms ^3.6 || ^4.0 || ^5.0 -> satisfiable by os2forms/os2forms[3.6.0, ..., 3.22.2, 4.0.0, 4.1.0, 5.0.0].
    - drupal/webform_node_element[1.2.0, ..., 1.x-dev] require drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (^10.3 || ^11.0).
    - os2forms/os2forms[3.6.0, ..., 3.22.2, 4.0.0, ..., 4.1.0, 5.0.0] require drupal/webform_node_element ^1.2 -> satisfiable by drupal/webform_node_element[1.2.0, 1.x-dev].

This also propagates to issues in drupal modules that require os2forms/os2forms in the form of a non-installable set of packages and therefore failing GitHub Actions when depending on a composer install. See OS2Forms GetOrganized for an example.

Going forward

Something needs to be done. While leniency helped out when the problem revolving non-updated packages showed up, it comes with lasting annoyances and a from scratch non-installable set of packages.

Firstly, it should be considered whether the Webform node element module is really needed.

If it is still needed going forward, we should maintain our own version in the OS2Forms organisation either as a newly created module or a fork of the original.

Footnotes

1. Webform Auto Exports now has a Drupal 10 ready version. ↩ ↩²

[ds-bellcom]

I can easily see the need to either update the module to be Drupal 10 compatible, or remove the module from OS2forms.

As far as I can see from a few of the installations that I have looked through, the module/element is used extensively, so I don't think it is a module that should be removed from OS2forms, unless there is an alternative. What do you use in Aarhus to get the same text on most forms (and which only needs to be updated in one place if it needs to be corrected)?

I think that is a discussion that the Coordination Group should have and then they should decide what should happen to the module.

@gBarlach, is this something you want to bring to the Coordination Group?

CC: @ChatBotBerg @Anna-itk

[jekuaitk]

I can easily see the need to either update the module to be Drupal 10 compatible, or remove the module from OS2forms.

As far as I can see from a few of the installations that I have looked through, the module/element is used extensively, so I don't think it is a module that should be removed from OS2forms, unless there is an alternative. What do you use in Aarhus to get the same text on most forms (and which only needs to be updated in one place if it needs to be corrected)?

I think that is a discussion that the Coordination Group should have and then they should decide what should happen to the module.

@gBarlach, is this something you want to bring to the Coordination Group?

CC: @ChatBotBerg @Anna-itk

Hi @ds-bellcom

I'm not aware of any such feature (sharing of text between webforms) being used on our installation. From a quick look i suppose that is exactly what the OS2forms webform texts module does. However, that module is not installed in our installation.

I agree that this is something that should be brought up in the coordination group.