The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Every kessai info file declares core_version_requirement: ^11.3, and drupal.org derives the packaged composer constraint from it. So drupal/kessai resolves as requiring drupal/core ^11.3, which excludes core 12, and any dependent that pulls kessai from packages.drupal.org cannot resolve a next-major test lane at all.
Measured in the yoyaku queue, whose payment submodule takes kessai as a dev dependency. Its composer (next major) job fails before installing anything:
Your requirements could not be resolved to an installable set of packages. - Root composer.json requires drupal/kessai 1.x-dev -> satisfiable by drupal/kessai[1.x-dev]. - drupal/kessai[dev-1.x, 1.x-dev] require drupal/core ^11.3 -> satisfiable by drupal/core[11.3.0-alpha1, ..., 11.x-dev].
That is not caused by anything in the dependent: the same job fails identically on an untouched commit of its default branch, so the whole Drupal 12 lane is dark for every project that depends on kessai.
What is actually unknown
Whether kessai works on Drupal 12. This project opts into the lane with OPT_IN_TEST_NEXT_MAJOR: 1, but the jobs are manual and have never been run, so no evidence exists either way. Widening the constraint without running them would just move the failure from resolution to runtime.
Proposed steps
- Run the next-major jobs and read what breaks. Deprecations reported by the phpstan next-major job come first, since those are the changes core will remove.
- Fix what they report, then widen
core_version_requirementto^11.3 || ^12in all six info files (the module, kessai_simulator, kessai_audit_trail, kessai_worldline, kessai_views and the test module). - Only then does a dependent's lane resolve, so this issue gates Drupal 12 readiness for anything built on kessai rather than being a cosmetic metadata change.
Worth noting for whoever picks this up: the dependent projects declare ^11.3 in their own info files too, so each of them needs the same widening after its own next-major run. Kessai is simply first in the chain, because nothing else can even resolve until it moves.
Issue fork kessai-3614379
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
mably commentedComment #5
mably commentedComment #7
mably commentedMerged to 1.x as e7197d1.
The lane could not resolve at all at first, for the reason this issue describes one level up: the development dependency
drupal/audit_trailpinsdrupal/core ^11.3, and once that was relaxed its own dependencydrupal/keypinned core in turn. Both are now listed in_LENIENT_ALLOW_LIST, so the next-major jobs install against Drupal 12 and report on kessai own code. audit_trail is tracked separately in #3614385: Declare Drupal 12 compatibility and turn on the next-major test lane.What the lane reported once it ran:
ReflectionMethod::setAccessible()in PaymentStorageSchemaTest. It has been a no-op since PHP 8.1, so the call is removed rather than replaced.After those two fixes all 17 test classes pass on Drupal 12, with the same test and assertion counts as on 11.3, and phpstan (next major) is green. So
core_version_requirementis widened to^11.3 || ^12on the module and all five submodules, with the README requirements line updated to match.One thing stays red on purpose: phpunit (next major) still exits non-zero even though every class passes. Every deprecation it reports originates in core or Symfony and none in kessai. They surface because Drupal 12 removes the SYMFONY_DEPRECATIONS_HELPER environment variable that the CI template still sets to suppress them, which is what the first reported deprecation says outright. That job is allow_failure by design, and the fix belongs in the templates rather than here.