Decomposing Packages (Symfony Live! San Francisco 2015)

Using Composer and Packagist makes using 3rd-party code easier but relying on 3rd-party code can have drawbacks. Projects are abandoned. Maintainers become unresponsive. Fortunately, Composer provides tools to help make these situations a little easier to manage. Learn how to leverage Composer features like "replace" and tools like Satis to manage forks of 3rd-party packages. See pros and cons of various methods so that you can feel more confident in how you decide to move forward with decomposing other people's packages.

Transcript

1. Decomposing Packages Beau Simensen @beausimensen • @moniidev • @thatpodcast joind.in/16047
2. <3 Composer
3. <3 Dependencies
4. :( Dependencies
5. Security
6. Change Tracking
7. Version Conflict
8. Slow Release Cycle
9. Abandoned
10. Different Goals
12. Working on Dependencies
13. Debugging
14. Bug Squashing
15. vendor Development
16. Live Debugging
17. @dev installed and/or --prefer-source
18. composer remote
19. Fork ...Clone and Develop In Another Directory
20. Override versus Rename and replace
21. Override
22. No need to rename a package just to work on it.
23. vendor/package is not always username/repo
24. Fork's composer.json { name: "their-vendor/their-package" }
25. Consumer's composer.json { "require": { "their-vendor/their-package": "^1.0" } }
26. Rename and replace
27. Fork's composer.json? { name: "my-vendor/their-package" }
28. Fork's composer.json { name: "my-vendor/their-package" } BAD
29. Consumer's composer.json { "require": { "their-vendor/their-package": "^1.0" } } my-vendor/their-package?!
30. Fork's composer.json { name: "my-vendor/their-package", replace: { "their-vendor/their-package": "self.version" } }
31. Working on a short-term solution? Avoid replace.
32. replace vs provide
33. provide
34. Virtual Packages
35. Interface's composer.json { "name": "psr/log", "require": { "psr/log-implementation": "1.0.0" } }
36. Implementation's composer.json { "name": "superawesome/fancy-logger", "provide": { "psr/log-implementation": "1.0.0" } }
37. Forces the inclusion of at least one package that provides psr/log-implementation.
38. No Conflicts
39. App's composer.json { "name": "superawesome/fancy-framework", "provide": { "psr/log-implementation": "1.0.0" }, "require": { "monolog/monolog": "^1.15" } }
40. replace
41. Allows a package to be installed instead of the package being replaced.
42. Symfony does this with symfony/symfony It replaces all of the component packages
43. replace and provide currently function in almost exactly the same way
44. They differ in Intention
45. App's composer.json { "name": "your-vendor/your-app", "replace": { "their-vendor/their-package": "1.0.3" } }
46. App's composer.json { "name": "your-vendor/your-app", "replace": { "their-vendor/their-package": "1.0.3" } } Meh. Provide more reasonable?
47. Replace says that your app should be installed instead of your dependency. Probably almost never what you mean.
48. App's composer.json { "name": "your-vendor/your-app", "provide": { "their-vendor/their-package": "1.0.3" } }
49. Provide says that your app or package has the code to satisfy the dependencies of another package. Probably more likely.
50. What if I actually do need to replace another package? You probably want to use self.version.
51. Forks's composer.json { "name": "your-vendor/their-package", "replace": { "their-vendor/their-package": "self.version" } }
53. How does Composer know where to find my forked package?
54. Repositories
55. Configuration composer config \ repositories.their-package \ vcs \ https://github.com/me/their-package
56. vcs Composer Repository Type
57. Consumer's composer.json { "require": { "their-vendor/their-package": "^1.0" }, "repositories": { "their-package": { "type": "vcs", "url": "https://github.com/me/their-package" } } }
58. Consumer's composer.json { "require": { "their-vendor/their-package": "^1.0" }, "repositories": { "their-package": { "type": "vcs", "url": "file:///path/to/clone-of/their-package" } } }
59. as
60. Consumer's composer.json { "require": { "their-vendor/their-package": "dev-my-fix as 1.0.5" }, "repositories": { "their-package": { "type": "vcs", "url": "file:///path/to/clone-of/their-package" } } }
61. path Composer repository type
62. Consumer's composer.json { "require": { "their-vendor/their-package": "^1.0" }, "repositories": { "their-package": { "type": "path", "url": "../their-package" } } }
64. Long-term
65. Abandoned
66. Refused or Ignored Pull Requests
67. Ownership
68. Change Tracking
70. Repositories
71. Global Repositories composer config --global \ repositories.their-package \ vcs \ https://github.com/me/their-package
72. VCS Repositories
73. Slow
74. Composer Repositories
75. Faster on edges
76. Packagist github.com/composer/packagist
77. Satis github.com/composer/satis
78. Static
79. Rebuild on Cron
80. Rebuild on Push
81. Toran toranproxy.com
82. "Dynamic"
83. Proxy
84. Disable Packagist
85. Satis and Toran Can download dependencies to be served locally.
87. Monolith The Cool Kids.
88. All Your Eggs in One Basket
89. Path Repository
90. Fiddler github.com/beberlei/fiddler
91. { "deps": [ "components/Foo", "vendor/symfony/symfony" ], "autoload": { "psr-0": {"Foo\\": "src/"} } }
92. Conductor github.com/mybuilder/conductor
93. Artifacts and Symlinks
95. Version Conflicts
96. Guzzle
98. ^2.7|3@dev
99. Stack & Pimple
100. Many Stack Middleware Have Pimple 1 at Their Core... { "name": "stack/session", "require": { "pimple/pimple": "^1.0" } }
101. And Are Completely Incompatible with Silex 2 { "name": "silex/silex", "require": { "pimple/pimple": "~3.0" } }
102. No Resolution
103. Question Why do Stack middleware depend on Pimple?
104. Reuse! Reuse! Reuse! Reuse! Reuse! Reuse!
105. Just Copy It™ — @davedevelopment
106. decomposer* github.com/paircasts/decomposer * kinda a joke... but the repo exists.
107. When you install a library, you are responsible for the code in that library. — https://igor.io/2013/09/24/dependency- responsibility.html
108. joind.in/16047 Questions? @beausimensen • @moniidev • @thatpodcast