Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Component and root composer.json dependency floors can drift undetected

オープン
#8,535 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
php

調査の方向性

Start by comparing the root composer.json with each src//composer.json, then inspect the PHPUnit (PHP 8.3) (Symfony lowest) job that runs composer update --prefer-lowest. Define the check around shared third-party constraints, including the listed dangerous mismatches, while keeping sibling api-platform/ constraints out of scope. Done means CI fails when the root permits a version excluded by a component and covers the intended sibling-consistency decision.

索引モデルが issue の本文から書いたものです。

説明

Problem

A component's src/*/composer.json can declare a dependency floor that the root composer.json does not, and nothing detects the divergence.

The root package autoloads src/ directly rather than installing the split components, so src/*/composer.json is inert during a root composer update. Constraints declared there never enter the root resolution. The root's own constraints must therefore independently cover what the code under src/ requires — but that duplication is maintained by hand.

How it surfaced

In #8534, src/Doctrine/Orm/composer.json was raised to doctrine/orm: ^2.17 || ^3.3, because Doctrine\ORM\Query\AST\PartialObjectExpression and the PARTIAL DQL grammar do not exist in 3.0.0–3.2.3. The root composer.json was left at ^2.17 || ^3.0.

The PHPUnit (PHP 8.3) (Symfony lowest) job runs composer update --prefer-lowest at the repo root, so it kept installing doctrine/orm 3.0.1 — a version the component itself declares unsupported. EagerLoadingExtension emitted partial x.{...} into a parser with no such grammar, and two ContextSwitchTest cases failed with:

[Syntax Error] line 0, col 38: Expected Doctrine\ORM\Query\TokenType::T_FROM, got '.'

raised from Paginator::getCountQuery().

Nothing pointed at the cause. The job that failed was not the job the change was meant to fix, the component's own test suite was green, and the failure looked like a version-resolution or flakiness problem before the root/component split turned out to be responsible.

Current state

A scan comparing every third-party constraint in src/*/composer.json against the root's finds 17 mismatches. Most are benign — the root is stricter than the component, e.g. symfony/serializer at ^7.4.9 || ^8.0.9 vs ^7.4 in eleven components.

The dangerous direction is the root being looser than a component, which is what bit #8534. Present examples:

component package component root
src/Laravel symfony/deprecation-contracts ^3.6 ^3.1
src/HttpCache guzzlehttp/guzzle ^6.0 || ^7.0 || ^8.0 ^6.0 || ^7.0

And #8534 left two siblings behind that should probably move with it:

component package component root
src/Doctrine/Common doctrine/orm ^2.17 || ^3.0 ^2.17 || ^3.3
src/Doctrine/Odm doctrine/doctrine-bundle ^2.11 || ^3.1 ^2.11.1 || ^3.1

Proposal

A CI check that compares shared third-party constraints between the root composer.json and each src/*/composer.json, failing when the root permits a version a component excludes. Sibling api-platform/* constraints are out of scope — those legitimately differ, since the root uses self.version.

Whether components should also be kept consistent with each other (the Doctrine/Common vs Doctrine/Orm case above) is a separate question worth deciding as part of this.

主要言語
PHP
スター
2.6k
フォーク
982
平均マージ
1日 16時間
マージ済み PR(30日)
59

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

api-platform/core のほかの issue

api-platform/core の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。