ADR-0001: Brug Composer til interne packages¶

Dato: 2024-01-15
Status: Accepted
Beslutningstagere: Dev-teamet

Context¶

Vi har gentagende kode på tværs af fem projekter: autentificering, billing-logik, API-klienter og delte utilities. Tidligere kopierede vi kode manuelt eller brugte git-subtrees, hvilket førte til divergerende versioner og svær vedligeholdelse.

Vi havde brug for en standardiseret måde at dele PHP-kode internt — med versionering, dependency resolution og reproducerbare builds.

Vi overvejede:

• Git subtrees/submodules — komplekst, dårlig DX, ingen versionering
• Private Packagist — betalt, mere end vi behøver
• Satis (self-hosted Composer repo) — open source, fuld kontrol
• GitHub Packages med Composer — tæt integration med vores eksisterende GitHub setup

Decision¶

Vi bruger Composer som package manager til alle interne PHP-libraries, med GitHub Packages (eller en self-hosted Satis-instans) som privat registry.

Hvert internt library lever i sit eget GitHub-repo med:

• Et versioneret composer.json
• Semantisk versionering via Git tags (v1.2.3)
• En docs/-mappe med dokumentation der synkroniseres til dette handbook

Alle projekter kræver interne packages via composer require acme/<package-name>.

Consequences¶

Positivt:

• Ét sted at vedligeholde delt kode — ingen kopiering
• Semantisk versionering giver eksplicit kontrol over breaking changes
• composer.lock sikrer reproducerbare builds i CI/CD
• Dokumentation kan trækkes automatisk ind i Engineering Handbook
• Onboarding af nye udviklere følger standard PHP-workflow

Negativt / trade-offs:

• Kræver at alle interne repos er tilgængelige fra CI/CD (token-håndtering)
• Breaking changes i et package kræver koordineret opdatering i afhængige projekter
• Overhead ved at oprette nyt repo + package-struktur for hvert library

Mitigering:

• Vi opretter en guide til nye Composer packages
• Breaking changes kommunikeres via CHANGELOG.md og Slack #dev-team
• Vi bruger ^-versionspin som default for at tillade patch- og minor-opdateringer