Kompositör utan kontinuerlig integration

Om du är en WordPress-utvecklare som använder Composer utan kontinuerlig integration, är det troligt att du står kvar med ett avgörande steg för att ta reda på hur du hanterar leverantörskatalogen när du distribuerar dina plugins.

Det är:

• Vi vet att det är en dålig idé att kasta hela leverantörskatalogen under källkontroll,
• Andra utvecklare som är bekanta med att använda Composer bör kunna komma igång utan att behöva mycket instruktioner,
• Kontinuerlig integration används inte av ett antal skäl,
• Och vi har kvar att behöva tillhandahålla en produkt i produktionskvalitet som använder vissa beroenden men inte andra.

Så mycket som ovanstående punkter kan beskriva vår situation, säger det oss inte vad vi kan göra med det.

Med andra ord, här är användningsfallet: Du har byggt ett WordPress-plugin för någon. Denna plugin använder en mängd olika beroenden som alla underhålls av Composer.

Du kontrollerar inte leverantörskatalogen i förvaret, men du använder inte heller kontinuerlig integration för att distribuera plugin-programmet. Istället är kunden, eller en tredje part.

Så vad då?

Distribution med kompositör utan kontinuerlig integration

Den korta versionen är denna:

Exportera huvudgrenen (eller släppgrenen eller vad du nu kallar den) från din lokala kopia av plugin-programmet, se till att du kör kommandot Composer som instruerar den att skapa leverantörskatalogen utan beroenden på utvecklingsnivå.

Sedan kan du bunta ihop det genererade arkivet och distribuera det till din kund.

Men hur?

För det första antar jag att den lokala kopian av ditt plugin inte har en kopia av leverantörskatalogen utan har all den senaste koden hämtad från fjärrförvaret.

Det vill säga, du har den senaste, stabila versionen av koden redo att släppas men du är ännu inte redo att göra det eftersom den inte har de nödvändiga beroenden för till exempel autoloading och annan liknande funktionalitet.

Det första steget kommer att vara att exportera det lokala förvaret till ett arkiv. Så här kan du göra det genom att släppa det på skrivbordet:

$ git archive -o ~/Desktop/plugin-name.zip HEAD

Instruera sedan Composer att installera de beroenden som ligger utanför direktivet require-dev i din composer.jsonfil:

$ composer install --no-dev

Nu kan du arkivera den genererade katalogen i ett plugin och distribuera den filen.

Är detta idealiskt?

Jag skulle inte säga att detta är idealiskt men det är en lösning på ett användningsfall som verkligen finns, så jag skulle säga att det är något som kan göras för att lösa ett specifikt problem.

I slutändan, om du letar efter ett sätt att distribuera ett WordPress-plugin som använder Composer utan kontinuerlig integration, är detta ett sätt att göra det.

Jag inser dock att det är ett specifikt användningsfall och har därför en specifik lösning.