Issue #3590125: Enforce xls_serialization ^2.1 via hook_install_requirements (alternative to the info.yml constraint)

Frank Mablyrequested to merge
issue/views_data_export_excel-3590125:3590125-install-requirements-hook into 1.x

Alternative implementation to MR !2 (merged) (the simple revert).

The info.yml (>=2.1) constraint added in MR !1 (merged) silently rejects xls_serialization's 2.1.x-dev branch — PHP's version_compare treats the x as a string less than any digit, so 2.1.x-dev < 2.1. Drupal's Component\\Version\\Constraint parser also ignores anything past major.minor, so no info.yml expression like >=2.0.999 or >=2.0.0-zzz works either — all of them collapse to >=2.0 and accept 2.0.x stable releases.

This MR moves the check into PHP using Composer's own Semver, which understands dev-version semantics natively:

installed (>=2.1) in info.yml Semver::satisfies(v, ^2.1)`
2.1.x-dev rejected accepted
2.1.0-dev accepted accepted
2.1.0 accepted accepted
2.0.x-dev rejected rejected
2.0.5 rejected rejected
3.0.0 accepted (no upper bound!) rejected

Changes

  • New OOP RequirementsHook class with #[Hook('install_requirements')] and #[Hook('runtime_requirements')] — runs on Drupal 11.3+.
  • New views_data_export_excel.install with a procedural hook_requirements BC stub for Drupal 10.3–11.2, suppressed on 11.3+ via #[LegacyRequirementsHook].
  • Missing version: (git/dev checkout with no Packagist-injected version line) is treated as 'trust it' — composer.json's ^2.1 already enforces the constraint at install time for that path.

Relation to MR !2 (merged)

MR !2 (merged) just reverts the broken info.yml constraint (stops the bleeding). This MR is the proper alternative — both surfaces the requirement in the module-install UI and accepts dev versions correctly. If this lands, MR !2 (merged) can either be merged first (and this layered on top) or replaced.

Merge request reports