Manage dev tool binaries with Phive instead of Composer
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- php
- Área
- build-system, tooling
Línea de trabajo
Start by reviewing composer.json to identify the development tools currently listed in require-dev, then check the project’s CI configuration and contributor setup for how those tools are installed and run. Compare that flow with the proposed .phive/phars.xml and Phive install command. Done means the tools run in CI and locally without conflicting with dependencies of projects that install the SDK, with the GPG trust and fallback questions resolved.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Background
Dev tools like PHPUnit, PHPStan and PHPCS are currently in require-dev inside composer.json. This couples the project's dependency graph to tooling versions and can cause conflicts when the SDK is installed in a host project.
Proposal: use Phive
Phive installs tools as standalone PHAR files, isolated from the project's Composer dependencies.
A .phive/phars.xml would look like:
<?xml version="1.0"?>
<phive xmlns="https://phar.io/phive">
<phar name="phpunit" version="^9.5" installed="9.6.34" location="./tools/phpunit" copy="false"/>
<phar name="phpstan" version="^1.10" installed="1.10.0" location="./tools/phpstan" copy="false"/>
<phar name="phpcs" version="^3.7" installed="3.7.2" location="./tools/phpcs" copy="false"/>
</phive>
Then in CI: phive install --trust-gpg-keys ...
Open questions
- Is this change worth the added complexity for contributors unfamiliar with Phive?
- Should we keep a
require-devfallback for environments without Phive? - How do we handle GPG key trust in CI?
- Lenguaje dominante
- PHP
- Estrellas
- 20
- Forks
- 3
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de openapi/openapi-php-sdk
-
Improve PHPDoc Consistency Across the CodebaseQuizá libre de nuevo @Seraphim200001 la tomó hace 139 días y no hay ningún pull request abierto. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
openapi/openapi-php-sdk#36 · 3 comentarios ·
-
enhancement help wanted
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
openapi/openapi-php-sdk#34 ·
-
good first issue question
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
openapi/openapi-php-sdk#33 · 2 comentarios ·
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
openapi/openapi-php-sdk#32 ·
-
help wanted question
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
openapi/openapi-php-sdk#31 ·
Todos los issues de openapi/openapi-php-sdk
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
matomo-org/device-detector#8405 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 4 días