Manage dev tool binaries with Phive instead of Composer
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- php
- Ambito
- build-system, tooling
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- PHP
- Stelle
- 20
- Fork
- 3
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di openapi/openapi-php-sdk
-
Improve PHPDoc Consistency Across the CodebaseForse di nuovo libera @Seraphim200001 l’ha presa 138 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
openapi/openapi-php-sdk#36 · 3 commenti ·
-
enhancement help wanted
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#34 ·
-
good first issue question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
openapi/openapi-php-sdk#33 · 2 commenti ·
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#32 ·
-
help wanted question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
openapi/openapi-php-sdk#31 ·
Tutte le issue di openapi/openapi-php-sdk
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
scanaislop/aislop#482 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
humanmade/publication-checklist#73 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Werkstattl/OpenBlogware#92 ·