Manage dev tool binaries with Phive instead of Composer
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- php
- Bereich
- build-system, tooling
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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?
- Vorherrschende Sprache
- PHP
- Sterne
- 20
- Forks
- 3
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus openapi/openapi-php-sdk
-
Improve PHPDoc Consistency Across the CodebaseEvtl. wieder frei @Seraphim200001 hat das vor 139 Tagen übernommen, und es ist kein Pull Request offen. Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
openapi/openapi-php-sdk#36 · 3 Kommentare ·
-
enhancement help wanted
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
openapi/openapi-php-sdk#34 ·
-
good first issue question
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
openapi/openapi-php-sdk#33 · 2 Kommentare ·
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
openapi/openapi-php-sdk#32 ·
-
help wanted question
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
openapi/openapi-php-sdk#31 ·
Alle Issues in openapi/openapi-php-sdk
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
woocommerce/woocommerce-google-analytics-integration#699 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Sidebar highlights two items when plugin routes share a prefix (/plugin/foo and /plugin/foo-bar)Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
getgrav/grav-plugin-admin2#195 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 60/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
ProfessionalWiki/NeoWiki#1675 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Incorrect documentationOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100