Manage dev tool binaries with Phive instead of Composer
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- php
- Domaine
- build-system, tooling
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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?
- Langage dominant
- PHP
- Étoiles
- 20
- Forks
- 3
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de openapi/openapi-php-sdk
-
Improve PHPDoc Consistency Across the CodebasePeut-être à nouveau libre @Seraphim200001 l’a pris il y a 140 jours, et aucune pull request n’est ouverte. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
openapi/openapi-php-sdk#36 · 3 commentaires ·
-
enhancement help wanted
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
openapi/openapi-php-sdk#34 ·
-
good first issue question
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
openapi/openapi-php-sdk#33 · 2 commentaires ·
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
openapi/openapi-php-sdk#32 ·
-
help wanted question
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
openapi/openapi-php-sdk#31 ·
Toutes les issues de openapi/openapi-php-sdk
Issues similaires
-
Good first issue: add laravel-inertia stack budget preset (Laravel 11 + Inertia.js + PHP 8.3)Ouverteenhancement good first issue help wanted
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
-
backend gamification P0
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
semanadeinformatica/website#461 ·
-
HttpRequestTrait fatals on WordPress 7.2: $blocked_http_requests clashes with WP_UnitTestCase_BaseOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
Invalid or expired state when the OAuth state is longer than 156 charactersPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 82/100