web-dev-qa-db-fra.com

Comment développer et inclure un package Composer?

Je cherche à développer un paquet en PHP, mais je ne veux pas qu'il soit immédiatement disponible sur GitHub ou quelque part. Il est assez facile d'inclure un fichier Packagist dans mon composer.json, mais comment puis-je ajouter un paquet local dans mon composer.json? De plus, devrais-je construire le paquet dans /vendor/foo/bar (par rapport à la racine composer.json), ou devrais-je le placer ailleurs?

Edit : Je suppose que ma question concerne la façon dont tous les autres écrivent leurs paquets. Chaque nouveau package est-il ajouté à Packagist, puis lorsque vous souhaitez tester vos modifications, vous vous engagez dans GitHub (ou ailleurs), puis vous le rétablissez via Composer? Cela semble vraiment inefficace.

phpcomposer-php
50
greggilbert

Étant donné que cette question comporte de nombreux composants/normes à expliquer, je vais essayer d’expliquer le plus possible et vous pouvez PM me chercher ou simplement sur Google pour des questions plus spécifiques au fur et à mesure de leur apparition.

Pour répondre à votre première question, "Comment puis-je ajouter un package local dans mon composer.json?":

Si vous entendez "ajouter un paquet local" par chargement automatique de votre classe/paquet, vous pouvez le faire en utilisant les options PSR-4 ou PSR-0 ou Classmap dans composer. 

Lire la suite

Vous pouvez le rechercher sur Google si vous avez besoin de plus d'informations sur PSR-0, PSR-4 et Classmap.

Exemple

"autoload": {
   "psr-4": { "Core\\": "src/Core" }  ## "standard": { "namespace" : "path/to/dir"}
}

Ou (éditer)

Si vous voulez réellement ajouter un paquet local:

  1. Créez un composer.json pour le paquet local, par exemple:

    {
   "name": "localPackage/core",
   "version": "dev-master"
}

    Vous pouvez également spécifier d'autres propriétés et/ou dépendances selon vos besoins.

  2. Compressez le package avec le fichier composer.json en tant que fichier racine dans le archive.Zip et placez-le à l'endroit souhaité.

  3. Dans l'autre projet/package dans lequel vous souhaitez inclure le package local, ajoutez le nom du package local au paramètre requis, comme 

    "localPackage/core": "dev-master"

    Ajoutez les éléments suivants sous le paramètre repositories:

    "repositories" : [
    {
        "type": "artifact",
        "url": "path/to/localPackage.Zip"
    }
]

Maintenant, si vous avez le paquet local sur git, alors il ne sera plus nécessaire de l’archiver (en omettant essentiellement l’étape 2) et il vous suffira de remplacer l’URL de l’exemple ci-dessus par le path/to/localPackage/.git.

(Fin de montage)

Maintenant, pour répondre à la question plus large: "Comment développer et inclure un package Composer?":

  1. Décidez la structure du répertoire. Communément c'est comme suit:

    /PackageRoot
    /src/PackageCore
    composer.json   ## this is your library’s composer.json
    LICENSE

    et configurez votre composer.json.

    Vous trouverez un exemple de l'un des fichiers composer.json à l'adresse http://Pastebin.com/tyHT01Xg .

  2. Téléchargez-le sur Github et identifiez la version . Utilisez Versioning Semantic (assurez-vous d’exclure/d’ignorer le répertoire vendor lors du téléchargement sur Github).

  3. Enregistrez le paquet avec Packagist (après vous être connecté).

    Si vous avez étiqueté votre commit avec v1.0.0 (ou similaire), cela apparaîtra dans votre tableau de bord Packagist pour ce paquet.

Maintenant, si tout est bien fait, vous devriez pouvoir utiliser votre bibliothèque comme dépendance dans d’autres projets en l’ajoutant au composer.json de ce projet.

25
ShalomSam

Il semble que la plupart des réponses sur ce fil ne sont pas "au courant". Je suis nouveau sur Composer moi-même, mais ces réponses sont trompeuses. La question pourrait simplement se poser comme suit: "Comment puis-je développer un package de composition".

Oui, vous pouvez utiliser un référentiel personnalisé ou télécharger un package non terminé et le mettre à jour après chaque modification. Ce n'est ni la solution correcte ni la réponse à la question.

Cela n'aide pas que La documentation officielle du compositeur ne l'indique pas d'emblée, mais vous pouvez voir l'en-tête sur la page de documentation de Libraries :

Chaque projet est un package

C'est très important de comprendre

composer.json:

La page mentionnée précédemment poursuit:

Afin de rendre ce paquet installable, vous devez lui donner un nom. Vous faites cela en ajoutant la propriété name dans composer.json

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

Dans cet exemple jusqu'à présent, nous avons un paquet requis et maintenant un nom. Notez le format vendor/name.

Passons maintenant au chargement automatique de nos propres fichiers, documentés sur la page Utilisation de base .

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}

Cela chargera automatiquement les fichiers de classe namespaced dans le répertoire src/Acme.

Pour le plaisir.

Installer la mise à jour

Installez ou mettez à jour le paquet avec la commande:

composer update

ou

php composer.phar update

Cela téléchargera les packages requis et créera le fichier autoload.php.

La structure de notre projet devrait ressembler à ce qui suit:

src
    Acme
        Foo.php
vendor
    monolog
        ...
composer.json

Comprenant

Maintenant pour tester.

Inclure autoload.php

require_once 'path/to/project/vendor/autoload.php';

En supposant que Foo.php ressemble à ceci:

<?php

namespace Acme;

class Foo {
    public static function bar(){
        return 'baz';
    }
}

?>

nous pouvons alors appeler cela de notre script:

echo Acme\Foo::bar(); // baz

S'il vous plaît corriger toute information trompeuse que j'ai pu avoir déclaré. C'est ce qui semble être la solution à une question populaire.

10
iautomation

Voici un récapitulatif des solutions et des miennes

  1. publier sur packagiste

Puisque vous ne voulez pas encore publier, vous êtes en développement, c'est une mauvaise option.

  1. télécharger github

Vous pouvez ne pas vouloir publier votre source de bibliothèque sur github, ne pas vouloir payer pour un repo privé ou pouvoir utiliser un service cloud externe (en raison de politiques politiques ou de réseau).

  1. Zip votre bibliothèque

Vous pouvez utiliser le chemin du référentiel composer dans votre exemple d'implémentation pour pointer sur un fichier Zip local en tant que version. Vous devrez re-Zip chaque fois que vous apportez une modification à la bibliothèque, même avec un fichier de commandes pour le faire, c'est dégoûtant.

  1. chargez-le sur le repit git/svn local sur votre machine

Nous nous en approchons, mais vous devrez faire une mise à jour du compositeur chaque fois que vous changez de bibliothèque et que vous voulez tester votre exemple d'implémentation. Cela imite les productions mais est lourd. Personnellement, je recommande cette solution, même si ce n'est pas sans cervelle.

  1. Chargement automatique de la bibliothèque directement (sortof fait ce que vous voulez)

C'est un hack, mais vous pouvez simplement ajouter:

{    
  "require": {
  },
  "autoload": {
    "psr-4": { 
      "yourlibnamespace": "D:\\Code\\yourlib\\src\\" 
    }
  }

}

Veuillez noter que vous devrez copier + coller la section 'require' de votre lib dans votre exemple d'implémentation. Changez 'yourlibnamespace' en votre espace de noms de bibliothèque et "D:\Code\yourlib\src \" en votre chemin local vers votre source de bibliothèque.

De cette façon, tous les changements sont immédiatement reflétés. Cependant, vous n'utiliserez ni ne testerez pas le fichier composer.json de votre bibliothèque. Si vous modifiez une exigence de votre bibliothèque .json, elle ne sera pas transmise du tout. Cela présente donc de gros inconvénients, mais fait ce que vous voulez, à savoir tester immédiatement l’implémentation de votre bibliothèque avec le moins de commandes possible.

  1. ajoutez votre exemple d'implémentation directement dans l'arborescence de votre bibliothèque (recommandé)

En général, vous n'avez que src\et tests \, mais beaucoup ont des exemples\où vous pouvez trouver des exemples d'implémentations. Au fur et à mesure que vous développez votre application, vous pouvez contribuer à ces exemples d'implémentation. Vous pouvez le faire dans un repo local git/svn, et vous avez l’avantage d’obtenir le "require" de la bibliothèque, plus l’espace de nom automatiquement. C'est le meilleur des mondes. Je recommande cette méthode.

7
Finlay Beaton

Pour rendre le développement plus efficace, il suffit de faire un lien symbolique du référentiel de développement vers un répertoire qui l'a déjà installé. 

Par exemple, si /Code/project-1 nécessite un package dans /Code/package-1, je:

  1. Validez package-1 dans GitHub (peut même être privé). 
  2. Je dis ensuite à project-1 de l'installer à l'aide d'un référentiel personnalisé (voir les autres réponses pour obtenir le lien vers la configuration du référentiel). 
  3. Une fois qu'il est installé, je symlink /Code/project-1/vendor/developer/package-1 à /Code/package-1. 

Ainsi, lorsque je modifie /Code/package-1, cela se reflète immédiatement dans /Code/project-1.

5
Adam Engebretson

Peut-être que l'ajout d'un référentiel personnalisé vous aidera?

https://github.com/composer/composer/blob/master/doc/05-repositories.md

Vous pouvez très facilement configurer un référentiel git local avec votre bibliothèque.

Bien sûr, si vous utilisez composer pour gérer les dépendances, vous devez créer votre bibliothèque ailleurs et la télécharger au format vendeur/via composeur car c'est tout ce que je suppose.

5
fsw

C’est mon flux de création et de développement local d’un nouveau package Composer:

  1. Créer un nouveau référentiel pour le paquet sur GitHub (juste un exemple)
  2. Ajoutez-le à la base de données du compositeur (packagist.org)
  3. Ajoutez-le à votre projet principal via Composer Required. C’est là que vous commencez à vous demander comment appliquer rapidement les correctifs.
  4. Clonez-le sur votre machine locale quelque part, c'est là que vous le développez
  5. Maintenant, pour tester votre version locale, ajoutez une instruction php require () dans laquelle vous chargez les fichiers de classe en question. L'autoloader ne chargera pas celui téléchargé via composeur, mais votre disque local. 
  6. Lorsque vous avez terminé le correctif, supprimez/commentez l'instruction require pour revenir à l'utilisation de la version composer du package.
  7. Commettez toutes les modifications, marquez les commits et Push to GitHub; le crochet se déclenche pour mettre à jour Composer. Exécutez la mise à jour du compositeur sur votre projet principal, le package est mis à jour vers votre version locale.

Ce n’est pas encore idéal, mais le travail est fait pour les paquets de taille petite à moyenne.

5
George Kagan

Mon flux de travail ne répond pas complètement à la question du PO mais peut être utile pour les autres.

  1. J'aime développer un paquet/lib réutilisable dans un projet réel et je ne veux pas passer par git/composer localement.
  2. De plus, je n'aime pas charger le paquet différemment localement par rapport à la production (par exemple, via une instruction locale ou un paramètre de composition local).

Donc, ce que je fais est simple: j'ajoute le paquet directement dans le répertoire du fournisseur, directement ou à l'aide d'un lien symbolique.

désavantages

  1. Lors de l’utilisation de composer update/install, votre paquet peut être écrasé. (J'ai donc tendance à mettre à jour ou à ajouter des dépendances une par une, pendant ce temps).
  2. Lorsqu'il n'est pas prudent, l'installation de composer dans l'environnement de production peut installer une version différente. Alors continuez à pousser vos balises package et version !!
  3. Changer les dépendances du paquet et le charger dans la mise à jour du composeur du projet parent écrase le dossier du paquet
0
roelleor