Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Component and root composer.json dependency floors can drift undetected

未关闭
  • 哪里不对？
#8,535 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
php
领域
build-system, ci-cd

调研方向

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
派生
989
平均合并
1 天 17 小时
30 天内合并 PR
81

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

api-platform/core 的其他 Issue

查看 api-platform/core 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。