Managing Dependencies with Composer (Midwest PHP 2014)

Traditionally, managing third-party code in PHP projects has not been a trivial task. Fortunately, the PHP community now has Composer, a top-notch dependency manager. Learn what Composer is and how you can put it to work for fun and profit. You will see how to set up a new project, find packages, as well as how to create and distribute your own packages.

Transcript

1. Managing Dependencies with Composer Midwest PHP March 15th, 2014
2. Beau Simensen @beausimensen +BeauSimensen beau.io
3. #composer look for simensen and say "hi" freenode IRC
4. Dragonfly Development @dflydev dflydev.com
5. boogio.com @wearboogio reflxlabsinc.com @reflxlabs
7. Dependency Management
8. composer.json
9. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
10. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
11. vendor-name/project-name A package's name cannot change and must be all lowercase
12. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
13. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
14. $ composer install Loading composer repositories with package information Installing dependencies (including require-dev) - Installing psr/log (1.0.0) - Installing symfony/routing (v2.3.7) - Installing symfony/debug (v2.3.7) - Installing symfony/http-foundation (v2.3.7) - Installing symfony/event-dispatcher (v2.3.7) - Installing symfony/http-kernel (v2.3.7) - Installing pimple/pimple (v1.1.0) - Installing silex/silex (v1.1.2) Writing lock file Generating autoload files $
15. The packages are installed into a directory named vendor
16. vendor =
17. require “vendor/autoload.php”;
18. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
19. Autoloading
20. # Acme\User is not defined ! $user = new Acme\User(); ! # Acme\User is defined
21. Magic! since 5
22. function ($class) { if ($class === "Acme\\Account\\User") { // do something to cause this class // to become defined require __DIR__."/src/user.inc"; } }
23. Composer is a configurable autoloader
24. Each Composer package gets to configure its own rules
25. psr-0
26. PHP-FIG PHP Framework Interoperability Group php-fig.com
27. –Larry Garfield "For sufficiently vague definitions of 'accepted', May 2009 is the date I use."
28. Namespaces are directories
29. Classes are files with .php suffix
30. Acme\Account\User
31. Acme/Account/User.php
32. PSR-0 also supports legacy PEAR style naming conventions
33. Acme\Account\User ! Acme_Account_User
34. Acme/Account/User.php ! Acme/Account/User.php
35. { "autoload": { "psr-0": { "Acme\\Account\\": "src" } } } ! new Acme\Account\User(); ! # src/Acme/Account/User.php
36. { "autoload": { "psr-0": { "Acme_Account_": "src" } } } ! new Acme_Account_User(); ! # src/Acme/Account/User.php
37. psr-4
38. PHP-FIG PHP Framework Interoperability Group php-fig.com
39. Accepted December 3rd, 2013
40. Composer currently recommends new projects use PSR-4
41. Very similar to PSR-0
42. Only supports namespaces (this means no PEAR style naming)
43. Requires a namespace prefix and base directory for mapping
44. Acme\Account\User (class) ! Acme\Account (namespace prefix) ! src (base directory) ! src/User.php (resulting file path)
45. { "autoload": { "psr-4": { "Acme\\Account\\": "src" } } } ! new Acme\Account\User(); ! # src/User.php
46. files
47. Explicitly include specific files
48. { “autoload”: { “files”: [ “src/foo.class.php”, “src/bar.class.php” ] } }
49. { “autoload”: { “files”: [“src/functions.php”] } }
50. { “autoload”: { “files”: [“src/autoload.php”] } }
51. The files autoloader is really an alwaysloader
52. classmap
53. A key => value map of class names to files on disk
54. { “autoload”: { “classmap”: [ “src/includes/”, “resources/config.php” ] } }
55. It will look inside .php and .inc files to find classes
56. The classmap is generated anytime Composer dumps its autoloader
57. Extremely fast and powerful but not very developer friendly
58. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
59. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
60. Versioning
61. If you want to leverage Composer to its fullest use Semantic Versioning
62. Semantic Versioning
63. semver.org
64. MAJOR.MINOR.PATCH Which number do you increment and why?
65. MAJOR.MINOR.PATCH When you break backwards compatibility
66. MAJOR.MINOR.PATCH When you add backwards compatible features
67. MAJOR.MINOR.PATCH When you make backwards compatible bug fixes
68. Pre-Release Identifiers Composer calls this "stability"
69. 1.0.0-alpha @alpha
70. 1.0.0-beta.1 @beta
71. 1.0.0-RC2 @RC
72. 1.0.0 (stable)
73. Version Constraints
74. Exact Versions 1.0.2
75. Ranges >=1.0.2,<2.0
76. Wildcards 1.0.*
77. Next Significant Release ~1.2 >=1.2,<2.0
78. Next Significant Release ~1.2.3 >=1.2.3,<1.3
79. Semantic Versioning let's you know what you are getting into
80. Safe 1.3.* Only get bug fixes
81. Reasonably Safe 1.* Get bug fixes and new features
82. Crazy Sauce * Composer allows this, but don't. Just don't.
83. Versions from Tags
84. 2.0.1 2.0.1 (2.0.*)
85. v2.0.1 2.0.1 (2.0.*)
86. 2.0.1-RC1 2.0.1-RC1 (2.0.*@RC)
87. 3.4-cuddly-cat 3.4-cuddly-cat (3.4-cuddly-cat)
88. 2.0.1g 2.0.1g (2.0.1g)
89. Versions from Branches
90. 2.0 2.0.x-dev (2.0.*@dev)
91. Named branches default to their name with a dev- prefix
92. master dev-master (dev-master)
93. testing dev-testing (dev-testing)
94. 2.0-experimental dev-2.0-experimental (2.0.*@dev won't work!)
95. Named branches can be aliased to be semver friendly
96. { “extra”: { “branch-alias”: { “dev-master”: “2.0.x-dev” } } }
97. master dev-master / 2.0.x-dev (dev-master or 2.0.*@dev)
98. –Don Gilbert “When starting a new library that is to be distributed via Packagist / Composer, be SURE to set up your dev- master branch alias.” https://twitter.com/dilbert4life/status/380137097614458881
99. requiring dev-master considered harmful
100. –Michael Dowling “I'm working on a new version of Guzzle. If you're using composer: stop using dev-master. Use a tagged release. Especially in production.” https://twitter.com/mtdowling/status/440901351657054208
101. Publishing and Discovery
102. packagist.org
103. Over 25,800 packages
104. Publishing is as easy as pasting your repositories GitHub URL
105. Check Packagist before you start a new library from scratch
106. Basic Usage
107. Install Composer getcomposer.org/download
108. $ curl -sS https://getcomposer.org/installer | php $ php composer.phar --version WARNING Security people think this is bad (but it is all the rage)
109. $ chmod 755 composer.phar $ mv composer.phar ~/bin/composer $ composer --version
110. composer.json and composer.lock
111. composer.json describes a package and its dependencies
112. { “name”: “acme/my-project”, “description”: “Acme’s My Project”, “license”: “MIT”, “require”: { “silex/silex”: “1.1.*” }, “autoload”: { “psr-4”: { “Acme\\MyProject\\”: “src” } } }
113. composer.lock describes exactly what should be installed
114. $ composer install Loading composer repositories with package information Installing dependencies (including require-dev) - Installing psr/log (1.0.0) - Installing symfony/routing (v2.3.7) - Installing symfony/debug (v2.3.7) - Installing symfony/http-foundation (v2.3.7) - Installing symfony/event-dispatcher (v2.3.7) - Installing symfony/http-kernel (v2.3.7) - Installing pimple/pimple (v1.1.0) - Installing silex/silex (v1.1.2) Writing lock file Generating autoload files $
115. Check your composer.lock into your repository
116. Common Commands
117. $ composer install If composer.lock exists, install exactly what is in the lock file. ! Otherwise, read composer.json to find out what should be installed, install the dependencies, and write out composer.lock.
118. $ composer update Installs dependencies from composer.json and creates or updates composer.lock.
119. $ composer require [pkg] Add a package to composer.json. ! The [pkg] is the name with a version constraint. ! foo/bar:1.0.0 or foo/bar=1.0.0 or "foo/bar 1.0.0"
120. $ composer diag Check environment and composer.json for common errors
121. $ composer validate Check composer.json for common errors
122. #composer
123. Pick an autoloading strategy
124. Use Semantic Versioning
125. Avoid requiring dev-master
126. Search Packagist first
127. Questions? @beausimensen +BeauSimensen ddd.io/mwphp14-composer
128. Migrating from PSR-0 to PSR-4
129. { "autoload": { "psr-0": { "Acme\\Account\\": "src" } } } ! new Acme\Account\User(); ! # src/Acme/Account/User.php
130. { "autoload": { "psr-4": { "Acme\\Account\\": "src/Acme/Account" } } } ! new Acme\Account\User(); ! # src/Acme/Account/User.php
131. Stability and the Root Package
132. A package is the root package while it is being developed
133. The root package is defined in the working composer.json
134. Stability is controlled by the root package
135. { “require”: { “silex/silex”: “~1.1@dev”, “symfony/http-foundation”: “@beta” }, “minimum-stability”: “alpha” }
136. Version Constraint Considerations
137. –Semantic Versioning “If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package).”
138. Libraries should generally have more permissive constraints
139. –Semantic Versioning “If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable).”
140. End projects may want to have more restrictive constraints