Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Component and root composer.json dependency floors can drift undetected

Abierto
  • ¿Algo no está bien?
#8,535 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php
Área
build-system, ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PHP
Estrellas
2.6k
Forks
987
Merge medio
1 d 10 h
PR fusionados (30 d)
76

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de api-platform/core

Todos los issues de api-platform/core

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.