2016/08/15. 2017/10/30. 2018/01/17. 2018/06/05. 2018/08/22. 2019/10/06. 2020-07-07. 2020-07-18. 2021-05-26. Ce jour, il faut toujours ajouter au tout nouveau composer.json le code suivant. Il s'agit de la copie automatique de nos personnalisations (et ne pas oublier le script sh lui-même): { "require": { ... }, "scripts": { "post-install-cmd": [ "sh copy_vendor-custom.sh" ] } } TL;DR: ===== In order of common workflow: (https://stackoverflow.com/questions/33449057/whats-the-purpose-of-composers-require-command answer by Tomáš Votruba) $ composer install // --dry-run installs all packages as mentioned in composer.lock (uses composer.json otherwise and creates composer.lock in the end) This is why we dont package composer.lock into our template projects, and have it created at the execution of composer install. Once composer.lock is created, we add it to the repository for the developers to share the same versions (until an update is decided). $ composer require vendor/package installs a new package and adds it to composer.json (creates that file if necessary) $ composer update // --with-dependencies updates current packages within the limits of composer.json (and updates composer.lock to reflect the new versions) $ composer remove vendor/package // --update-with-dependencies pour enlever aussi les dependencies removes the package and updates composer.json and comopser.lock to reflect the removal. Usage of json and lock file: composer.json describes the versions we want and our tolerance. composer update lit ce fichier et met à jour (ou installe si manquants) les paquets en comparant les nouvelles versions disponibles avec les besoins et des tolérances indiquées. Il met alors à jour le fichier composer.lock pour documenter les versions installées. composer require ajoute le nouveau composant indiqué à ce fichier, en le créant si nécessaire. composer.lock describes the current situation. composer install lit ce fichier pour installer les paquets avec les versions exactes indiquées. Ce n'est que si ce fichier est manquant que composer install utilise composer.json pour déterminer les paquets à installer, en fonction des besoins et tolérances qui y sont spécifiées. Il crée le composer.lock dans la foulée pour documenter les versions installées. Si les deux fichiers sont tous deux abents, composer install ne peut donc fonctionner. Notation des versions: Préférer la notation utilisant l'étoile en "1.2.*", c'est le plus simple. et n'utiliser la notation caret ^ que si on rencontre un cas difficile, et en tilde ~ si encore plus difficile. https://stackoverflow.com/questions/43135145/version-numbers-with-caret-and-tilde-in-composer-json Parfois la version de PHP dans composer.json est notée en ">=" et parfois en "^". ====== ATTENTION ! A chaque mise à jour des composants par Composer, vérifier dans le répertoire parallèle "vendor-custom" s'il y a des personnalisations-maison que nous devons recopier à nouveau vers "vendor". Lire par exemple à ce sujet la procédure en ce sens au application\third_party\vendor-custom\egulias\email-validator\EmailValidator\readme-ibonia.txt ========= OLD Copies existantes de ce document: D:\Softwares\@Development\@Platforms\PHP\PHP\Composer\readme-ibonia.txt D:\DataFiles\www\2017\mictslpaiement17i\application\third_party\composer.txt D:\DataFiles\www\_cipackages\ci226_2018\application\third_party\composer.txt A INTEGRER ========== https://devedge.wordpress.com/2015/05/16/a-few-thoughts-about-composer-and-how-people-use-it/ https://devedge.wordpress.com/2016/07/23/composer-what-you-should-know/ [Important!] https://stackoverflow.com/questions/19117871/what-is-the-difference-between-require-and-require-dev-sections-in-composer-json car nous suggère que vendor/ ne doit pas être suivi sous Git, mais seulement composer.json et composer.lock, de sorte que l'on exécute $ composer install sur la PREPROD pour avoir les outils listés sous "require-dev", mais qu'on vera $ composer install --no-dev sur la PROD pour ne plus les avoir. Autrement dit aussi, nous ne devions pas nous encombrer des composants dans Git, chaque développeur faisant ignorer ses copies locales... Cela est aussi confirmé ici au https://www.codementor.io/jadjoubran/php-tutorial-getting-started-with-composer-8sbn6fb6t où il est dit dans la section " Common workflow in a team environment" : "Add vendor to your .gitignore. This will instruct Git to ignore all the vendor folder. In that way each developer (in a team) will have a local copy of the required libraries." QUICK-START =========== Lorsqu'on créé un projet ou ajoute un composant Lorsqu'on participe à un projet Lorsqu'on désire mettre à jour les composants Lorsqu'on désire utiliser un composant dans un fichier PHP Lorsqu'on désire utiliser un composant dans CodeIgniter Lorsqu'on désire utiliser un composant dans Syfmony QUICK-REFERENCE =============== Pour mettre à jour Composer de temps à autre: $ composer self-update Updating to version X.Y.Z (stable channel). Downloading: 100% Use composer self-update --rollback to return to version A.B.C Pour ajouter une nouveau composant *globalement* via Composer (exemple): $ composer global require "fxp/composer-asset-plugin:~1.3" Changed current directory to C:/Users//AppData/Roaming/Composer ./composer.json has been created Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 1 install, 0 updates, 0 removals - Installing fxp/composer-asset-plugin (v1.4.4): Downloading (100%) Writing lock file Generating autoload files Pour ajouter un nouveau composant *au projet* via Composer: 1. Ouvrir le fichier application/third_party/composer.json existant et ajouter les spécifications/contraintes pour notre nouveau composant. Exemple: { "require": { "moneyphp/money": "*", "ddeboer/imap": "^1.0", "egulias/email-validator": "~2.1" "phpmailer/phpmailer": "~6.0.0" // Equivalent à 6.0.*, i.e. permettre les patchs ! } } Pour rappel, il y a de nombreux moyens d'indiquer les versions désirées/autorisées: Soit de façon exacte comme avec "1.0.2", soit avec une intervalle comme avec ">=1.0 <1.1 || >=1.2", ou avec "1.0 - 2.0" (amène jusqu'à 2.0.*), soit avec l'étoile en 1.0.*. Ainsi: "*" obtenir la version la plus récente "1.*" obtenir la version 1 avec la version mineure la plus récente "1.0.*" obtenir la version 1.0 avec le patch le plus récent On peut aussi utiliser les tilde (~) et caret (^), dits "Next Significant Release Operators" "~1.0" est équivalent à "1.*" est équivalent à >= 1.0.0 et < 2.0.0 "~1.0.0" est équivalent à "1.0.*" est équivalent à >= 1.0.0 et < 1.1.0 "^1.0" est équivalent à "1.*" est équivalent à >= 1.0.0 et < 2.0.0 "^1.0.0" est équivalent à "1.*" est équivalent à >= 1.0.0 et < 2.0.0 Entre nous la syntaxe en "*" nous semble la plus claire, et devrait être utilisée sauf lorsqu'on désire une marge d'évolution plus large. Si tel est le cas, alors le ~ est plus strict et le ^ est plus permissif. (see https://stackoverflow.com/questions/43135145/version-numbers-with-caret-and-tilde-in-composer-json) (see https://developer.happyr.com/always-use-caret-instead-of-tilde (see https://getcomposer.org/doc/articles/versions.md#writing-version-constraints dont l'usage des "Stability Constraints" tels que "-dev" et "-stable" non décrits ici): 2. Lancer $ composer update pour installer le nouveau composant. [!] Nous sommes entrain de changer d'avis et comprendre que c'est $ composer update qu'il faut faire au lieu de $ composer install. En effet et déjà, ceci provoque la protestation de Composer qui demande un update à la place. [BON] "INSTALL will install the packages from your composer.lock file [and only create .lock if it does not exist] while UPDATE will update and install the packages based on your composer.json file and write the changes in .lock" [OLD PAS BON:] A DOCUMENTER ET MODIFIER TOUT LE DOCUMENT en conséquence car il semblerait que nous ne comprenons une chose que maintenant: c'est le UPDATE qui sert à installer de nouveaux composants et le décrire dans le .lock ; tandis que l'INSTALL ne fait que lire le .lock et installer ce qui s'y trouve => différent de nos compréhensions d'avant, y compris pour les paragraphes immédiatement ci-après). Relire pour cela : https://stackoverflow.com/questions/33052195/what-are-the-differences-between-composer-update-and-composer-install Pour rappel, on ne lance $ composer update que *de temps en temps* sur le poste de développement afin de procéder à l' *upgrade* des différents composants selon leurs contraintes respectives. Si après tests (ex. tests unitaires) tout se passe bien, alors les mises à jour en préprod et prod se feront toutes seules via le déploiement des codes ainsi mis à jour (i.e. on ne fait jamais d'update directement/soi-même sur la préprod ni sur la prod). Pour rappel on ne fait $ composer require que si on installe le *tout premier* composant et on ne désire pas créer le fichier composer.json à la main. Mais nous ne voyons pas trop l'utilité de cette commande si on peut éditer le fichier dans un éditeur avec plus de latitude pour mettre au point. POURQUOI UTILISER COMPOSER ? ============================ "Stop making CodeIgniter libraries, Laravel bundles and Zend modules, make Composer packages." Dans notre cas particulier à nous pour notre framework CodeIgniter maison: * pour installer des composants tiers facilement * et avoir un mécanisme de mise à jour pour eux si nécessaire. SI COMPOSER lui-même N'EST PAS ENCORE INSTALLE: INSTALLATION GLOBALE ==================================================================== Note: ce qui suit est une installation globale de l'exécutable Composer. Il semblerait que parfois les projets optent pour une installation de Composer locale au projet. Pour Windows il s'agit d'un binaire .exe à installer, et qui met à jour aussi le PATH. 1. Downloaded from https://getcomposer.org/doc/00-intro.md and used for install, in the same page, https://getcomposer.org/doc/00-intro.md#installation-windows 2. Comme Composer a besoin d'utiliser une version quelleconque de PHP, elle detecte les versions présentes (notre Wampserver64) et nous propose de faire un choix. Comme nous avons des versions installées de la 5.3 jusqu'à la 7, nous choisissons la version 7. Nous pensons que ce choix n'est pas très important, Composer devant fonctionner correctement avec différentes versions. 3. Nous ignorons le paramétrage de proxy. A part cela rien de spécial. DOCUMENTATION OFFICIELLE ======================== https://getcomposer.org/doc/ QUELQUES PRINCIPES ================== L'utilisation habituelle est (à supposer que Composer est installé globalement et exécutable en ligne de commande avec une simple $ composer ..., sinon, toutes les commandes seront en $ php composer.phar ...): 1. On crée un fichier composer.json pour déclarer les composants que l'on voudrait avoir et leurs dépendances. Pour chacun des composants, ce fichier peut indiquer des versions plus ou moins strictes telles que "*" (obtenir la version la plus récente), "1.*" (obtenir la version 1.x la la plus récente), "1.7.*" (rester à la version 1.7 mais avec les patchs les plus à jour). Précisions utiles: Rappel préalable des numérotations de semantic versioning (SemVer, https://semver.org/): Given a version number MAJOR.MINOR.PATCH, increment the: * MAJOR version when you make incompatible API changes, * MINOR version when you add functionality in a backwards-compatible manner, and * PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Que signifie le tilde "~" comme dans "~1.2" par exemple ? "~" signifie le dernier chiffre peut varier à la hausse. "~1.2" : "Cette version 1.2 ou plus, mais sans passer à la version 2" "~1.2.3": "Cette version 1.2.3 ou plus, mais sans passer à la version 1.3" The ~ operator is best explained by example: ~1.2 is equivalent to >=1.2 <2.0.0, while ~1.2.3 is equivalent to >=1.2.3 <1.3.0. As you can see it is mostly useful for projects respecting semantic versioning. A common usage would be to mark the minimum minor version you depend on, like ~1.2 (which allows anything up to, but not including, 2.0). Since in theory there should be no backwards compatibility breaks until 2.0, that works well. Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up. Que signifie le caret "^" comme dans "^1.2" par exemple ? "^" signifie les versions MINOR et PATCH peuvent tous deux évoluer à la hausse puisque la rétro-compatibilité est réputée garantie même pour une nouvelle version MINOR. "^1.2" : "Cette version 1.2 ou plus, mais sans passer à la version 2" "^1.2.3": "Cette version 1.2.3 ou plus, mais sans passer à la version 2" (alors qu'avec le tilde, s'est sans passer à la version 1.3) Les deux ont donc des points de départ différents, mais la même limitation. The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0. This is the recommended operator for maximum interoperability when writing library code. 2. [FIRST TIME and in PREPROD/PROD] On exécute $ composer install et les composants sont téléchargés et installés chacun dans leurs sous-répertoires respectifs, sous un sous-répertoire ./vendor du répertoire courant (tous créés si nécessaire). Ce qui est moins clair pour le débutant c'est que $ composer install est AUSSI UTILISE pour la MISE A JOUR sécurisée des composants, avec un COMPORTEMENT DIFFERENT de $ composer update (voir plus loin): En effet: * "install" est conçu pour respecter les versions exactes d'un fichier composer.lock si celui-ci existe déjà, tandis que * "update" est conçu pour aller chercher explicitement la version la plus récente (sous la contrainte de composer.json) et mettre ensuite à jour le contenu de composer.lock. Par conséquent: Par conséquent: * EN PREPROD et PROD on exécute "install" pour les mises à jour en se basant sur le composer.lock mis sous version control. * EN DEV on exécute de temps en temps "update" pour obtenir des versions plus récentes de composants, en ajustant au préalable composer.json si nécessaire. See: [GOOD] https://adamcod.es/2013/03/07/composer-install-vs-composer-update.html [REFERENCE] https://getcomposer.org/doc/03-cli.md#install 3. On peut aussi éviter la création à la main de composer.json en faisant: $ composer require /:2.* /:dev-master ... ce qui a pour effet de générer le fichier puis ensuite lancer les installations. https://getcomposer.org/doc/03-cli.md#require Nous sommes d'avis que c'est peut-être bon pour le tout premier composant installé, mais qu'il est ensuite préférable de ne pas laisser au hasard de "require" la modification de notre fichier composer.json ? 4. [DEV TIME ONLY] De temps en temps en *développement* on fait $ composer update (ou $ composer upgrade , qui est un simple synonyme) afin d'obtenir les versions les plus récentes des composantes, mais respectant strictement les contraintes de composer.json : Par exemple si la version est "1.2.*", alors l'update restera avec les versions majeur et mineur de 1 et 2, mais téléchargera le patch le plus récent possible. Le fichier composer.lock sera ensuite mis à jour pour mémoriser cette version la plus récente (soit toujours "1.2.*" dans composer.json et "1.2.37" par exemple dans composer.lock). Autre exemple si la version est "*" dans composer.json, alors la version la plus récente sera installée par l'update, puis cette version sera notée dans composer.lock Pour ces raisons, on ne doit *JAMAIS LANCER* $ composer update NI en PREPROD/STAGING, NI en PROD/LIVE. https://getcomposer.org/doc/03-cli.md#update Pour résumer: * $ composer update is mostly used in the 'development phase', to upgrade our project packages according to what we have specified in the composer.json file, * $ composer install is primarily used in the 'deploying phase' to install our application on a production server or on a testing environment, using the same dependencies stored in the composer.lock file created by composer update. => NOUS NE SOMMES MEME PAS D'ACCORD AVEC CELA puisque le gestionnaire de code source déploie déjà le code. Personne ne fera un "install" manuel sur la préprod ou la prod ! Par ailleurs cela pose de nombreux problèmes sur ce type de serveurs: * Ces serveurs ne doivent pas avoir du Git et du Composer pour aller chercher des composants ailleurs. * On sera tout penauds si les liens disparaissent et que l'on ne peut plus installer. On a au mieux des dépensances inutiles et au pire des problèmes de sécurité UTILISATION générale hors framework =================================== D'après https://philsturgeon.uk/php/2012/05/07/composer-with-codeigniter/ nous déduisons que la procédure globale serait a. [run-once] Avoir Composer d'installé, de préférence globalement, ce qui est notre cas avec la manière de faire ci-dessus. b. Créer le fichier composer.json suivant à la racine du projet PHP: { "require": { "someeditor/somelibrary": "*" } } Exemple concret: "moneyphp/money" c. Lancer l'installation de ladite librairie avec (en étant donc aux côtés du fichier JSON) $ composer install // Ou composer.phar install "Then you should notice composer creating a ./vendors folder in your application and code will be installed there." d. To autoload this newly installed code all you need to do is drop a single line of PHP into your root index.php include_once './vendor/autoload.php'; [!] D'autres articles avertissent qu'il faut mettre cette ligne avant la ligne qui appelle require_once BASEPATH.'core/CodeIgniter.php'; (https://stackoverflow.com/questions/13741917/how-to-use-composer-packages-in-codeigniter) Mais voir installation spécifique à CodeIgniter ci-après. e. Now I can use Buzz happily, along with any other PSR-0 code that I install via Composer: $browser = new SomeEditor\SomeLibrary(); UTILISATION AVEC CodeIgniter 2.x {9513F2B7} ------------------------------------------- 1. Dans application/third_party (notre choix) nous avons créé le fichier composer.json avec [par exemple] comme contenu une référence à la bibliothèque http://moneyphp.org: { "require": { "moneyphp/money": "*" } } 2. Puis en restant dans le répertoire nous faisons en ligne de commande: $ composer install 3. Ceci créé la structure de répertoires suivant à l'endroit même: vendor\ composer\... moneyphp\ money\... autoload.php ainsi que le fichier composer.lock qu'il ne faut **PAS** supprimer (ce n'est PAS UN FICHIER TEMPORAIRE comme le nom peut le laisser à penser). 4. Pour une utilisation "web" du nouveau composant, nous ajoutons dans la page ./index.php à la racine du site (au dessus du répertoire application/) et *avant* la ligne appelant core/CodeIgniter.php: include_once APPPATH . 'third_party/vendor/autoload.php'; // Testé OK ! Pour une utilisation en CLI du nouveau composant, nous ajoutons la même ligne à application/third_party/CIUnit/bootstrap_phpunit.php, toujours *avant* la ligne appelant core/CodeIgniter.php: include_once APPPATH . 'third_party/vendor/autoload.php'; // Testé OK ! [!] NE PAS oublier de modifier l'index.php sur sur la préproduction et la production. [!] NE PAS oublier de modifier bootstrap_phpunit.php sur l'intégration continue. 5. Exemple de code de test ensuite dans tests/libraries/MoneyTest.php: use Money\Currency; use Money\Money; class MoneyTest extends CIUnit_TestCase { var $MyReader; public function testMoneyUsagePatterns() { $fiver = new Money(500, new Currency('USD')); // ... do assertions. } } AJOUT D'UN DEUXIEME (n-ième) COMPOSANT (2018/01/18) ------------------------------------------------------------------------- Nous n'avons malheureusement pas documenté ce que nous avons fait lorsque nous avons eu à ajouter un nouveau composant à notre projet avec l'aide de Composer (Nous avons tout juste retrouvé la date grâce à Git). Il s'est agi de l'ajout du composant ddboer/imap sur https://github.com/ddeboer/imap/ La procédure y conseillée pour l'installation du composant est "$ composer require ddeboer/imap" Mais nous supposons que nous avons suivi la même procédure que ci-dessus et voici les changements que nous avons observés: 1. Nous avons probablement modifié à la main le fichier application\third_party\composer.json comme suit, avec l'ajout de la ligne '"ddeboer/imap": "^0.5.2"' (voir plus haut section QUELQUES PRINCIPES pour l'explication du circonflexe) { "require": { "moneyphp/money": "*", "ddeboer/imap": "^0.5.2" } } 2. Puis nous avons du lancer, toujours depuis application\third_party\ $ composer install Ce qui a créé le sous-répertoire vendor\ddeboer\imap\ 3. Le fichier application\third_party\composer.lock a été modifié automatiquement pour inclure le nouveau composant dans sa section packages (ici avec plusieurs sous-composants "imap" et "transcoder"): "packages": [ { "name": "ddeboer/imap", "version": "0.5.2", // ... }, { "name": "ddeboer/transcoder", "version": "1.0.0", // ... }, // ... ], // ... 4. Nous remarquons une chose importante: la commande d'installation a AUSSI mis à jour le composant (donc les composants) précédement installé. Si dans le composer.lock précédent la version était la 3.0.8, elle a évolué vers une version plus récente: "packages": [ // ... { "name": "moneyphp/money", "version": "v3.1.0", // ... }, // ... ], // ... Il s'agit de l'effet de notre choix de "*" dans composer.json: Si nous ne voulons pas que notre composant "moneyphp/money" évolue hors de contrôle (change de verion PHP par exemple), nous devrions voir quelle version spécifier. => Voir pour cela la section QUELQUES PRINCIPES plus haut pour le versioning. AJOUT D'UN TROISIEME (n-ième) COMPOSANT (2018/06/05) ------------------------------------------------------------------------- Ajout documenté cette fois: 1. Nous allons dans applications/third_party/, et ajoutons le composant au composer.json qui s'y trouve déjà. { "require": { "moneyphp/money": "*", "ddeboer/imap": "^1.0", "egulias/email-validator": "~2.1" // La nouvelle ligne } } Note: Notre choix de tilde ~ pour l'évolution de la version, signifie qu'on ne veut pas passer à la version 3. Pour les deux composants en ^ et en ~ il n'y a pas de différence ici puisque les deux syntaxes empêchent simplement le passage à une version MAJOR suivante. C'est lorsqu'on spécifie la partie PATCH (le troisième chiffre) que la différence existe, car le tilde ~ sera plus strict et empêchera le passage à la version MINOR suivante, tandis que le caret ^ restera plus libéral en se limitant toujours à la version MAJOR. (voir QUELQUES PRINCIPES plus haut pour le versioning). Note: Nous laissons le composant "moneyhp/money" à une évolution très libérale de "*" ici car nous sommes dans un exemple où nous n'avons pas encore commencé à l'utiliser dans le code et pouvons permettre son évolution sans crainte (mais avec le risque d'une dépendance à une version PHP trop élevée...). 2. En ligne de commande au même endroit nous exécutons: $ composer install 3. Nous pouvons parfois avoir le message suivant: Loading composer repositories with package information Installing dependencies (including require-dev) from lock file Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them. Nothing to install or update Generating autoload files Ce qui est une invitation à mettre à jour nos composants et le fichier .lock avec la commande "update", alors que "install" ne fait que lire ledit fichier .lock et réaliser les installations qu'il commande. (voir QUELQUES PRINCIPES pour détails, notamment la différence "install"). Nous lançons donc: $ composer update Ce qui a pour effet: Loading composer repositories with package information Updating dependencies (including require-dev) - Removing moneyphp/money (v3.1.0) - Installing moneyphp/money (v3.1.3) Downloading: 100% - Removing ddeboer/imap (1.2.0) - Installing ddeboer/imap (1.5.1) Downloading: 100% - Installing doctrine/lexer (v1.0.1) Downloading: 100% - Installing egulias/email-validator (2.1.4) Downloading: 100% Writing lock file Generating autoload files Nous remarquons qu'composant "doctrine/lexer" a été installé sans que nous le demandions. C'est parce que c'est sans doute une dépendance de "egulias/email-validator" (ou de l'un des autres composants qui peut avoir évolué entre temps). COMPRENDRE LA PUISSANCE DE composer.lock (2018/01/17 ; lire d'abord QUELQUES PRINCIPES) ------------------------------------------------------------------------- https://stackoverflow.com/questions/10674641/composer-lock-how-does-it-work [Shahzaib Hayat Khan] "The point of the lock file is to record the exact versions that are installed so they can be re-installed. This means that if you have a version spec of 1.* and your co-worker runs composer update which installs 1.2.4, and then commits the composer.lock file, when you do composer install, you will also get 1.2.4, even if 1.3.0 has been released. This ensures everybody working on the project has the same exact version. Read more here Composer: It's All About the Lock File (https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file)" [Dilhan Maduranga] composer.lock records the exact versions that are installed. So that you are in the same versions with your co-workers. So if you do: $ composer install // Conforms strictly to lock file Checks for composer.lock file If not, auto generates composer.lock file (using composer update) Installs the specified versions recorded in the composer.lock file $ composer update // Tries to get latest version according to json file then updates lock file Goes through the composer.json file Checks availability of newer (latest) versions, based on the version criteria mentioned (e.g. 1.12.*) Installs the latest possible (according to above) versions Updates composer.lock file with installed versions So in a simple check list, If you want to keep all co-workers in the same versions as you... Commit your composer.lock to GIT (or vcs you have) Ask others to get that version of composer.lock file Always use $ composer install to get the correct dependencies If you want to upgrade the system dependencies to new versions Check the composer.json file for version specs. Do a composer update This will change the composer.lock file with newest versions Commit it to the GIT (or vcs) Ask others to get it and composer install Following will be a very good reading https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file Enjoy the power of composer.lock file!