How I Learned to Stop Worrying and Love Composer - php[world] 2015

How I Learned to Stop Worrying and Love Composer - php[world] 2015

WordPress extensions, Drupal modules, Magento extensions — developers are building amazing features for each platform. But what if, instead of building platform-specific features, we built reusable packages? All of our platforms can be used with Composer — Magento 2 is even fully installable via Composer & developers can pull in specific Magento components to non-Magento projects, as well. However, we still write extensions for our platform & don't write reusable PHP packages. Let's look at how we all benefit by changing this mindset and how to start writing reusable cross-platform packages.


Joshua Warren

November 19, 2015



  2. None
  3. Slides will be available at #phpworld

  4. My Experience PHP Developer Since 1999 Founded Creatuity in

    2008 Focused on the Magento platform Previous experience w/WordPress, Joomla, Drupal, Yii #phpworld
  5. This concept was inspired by all of you at

    php[world] 2014 #phpworld
  6. “Bringing the entire world of PHP one step closer

    together” #phpworld
  7. Cross-pollinating ideas between PHP frameworks and applications #phpworld

  8. One common idea I heard repeatedly at php[world] 2014

  9. None
  10. Open source allows us to pool our efforts #phpworld

  11. We accomplish so much more together than we could

    on our own #phpworld
  12. Composer is an amazing tool that breaks down barriers

    to re-using open source libraries #phpworld
  13. Every framework represented at php[world] can be used with

    composer #phpworld
  14. Many of the frameworks here can be installed with

    Composer, including Magento 2 #phpworld
  15. Many of the frameworks, though - especially those closest

    to end-users - use their own module formats #phpworld
  16. That’s a problem #phpworld

  17. None
  18. None
  19. The community around each framework is developing in their

    own silo #phpworld
  20. We’re duplicating (wasting!) massive amounts of effort #phpworld

  21. We all hate spam, right? #phpworld

  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. if Akismet makes a breaking change, that’s 8 developers

    that need to make the same updates #phpworld
  31. Repeat this exercise on packagist for any popular technology

  32. We’re wasting so much of our effort on duplicating

    each other’s work needlessly #phpworld
  33. Thousands of developer-hours a year are wasted just building

    framework-specific solutions #phpworld
  34. In the words of Bob Newhart on Mad TV…

  35. STOP IT! #phpworld

  36. No excuses, just stop it. #phpworld

  37. Let’s write composer packages that can work on all

    frameworks #phpworld
  38. contribute to existing PHP packages instead of creating framework-specific

    packages #phpworld
  39. We’re smart people. We’re developers. You could even say…

  40. None
  41. We can revolutionize the web if we focus our

    efforts on solving new problems #phpworld
  42. There’s three steps to making this change #phpworld

  43. Step 1: change your way of thinking #phpworld

  44. Stop looking for framework- specific extensions #phpworld

  45. Start your search on Packagist #phpworld

  46. If you find a library that doesn’t do quite

    what you need, improve it #phpworld
  47. Adapt those existing libraries to your framework #phpworld

  48. You benefit - you don’t have to re-write functionality

    someone else has already written #phpworld
  49. The package author benefits from your feedback and contributions

  50. The entire community benefits from having a focused group

    of high-quality packages #phpworld
  51. Adapting these libraries to your framework gets time consuming

  52. If only we had access to some sort of

    tool that could easily automate repetitive actions… #phpworld
  53. None
  54. Step 2: Develop a community standard for universal PHP

    libraries #phpworld
  55. There are two ways to approach universal PHP packages

  56. First - packages that have multi- framework support built

    in #phpworld
  57. Each package contains everything needed for that package to

    run on all PHP frameworks #phpworld
  58. This puts more work on the package author, but

    less work on the frameworks and the package users #phpworld
  59. The second approach is to build a standard, universal

    package format #phpworld
  60. Each framework would then need an adapter or bridge

    to understand these packages #phpworld
  61. Simplifies things for package authors #phpworld

  62. Early package users have more work to do -

    each framework will need an adapter #phpworld
  63. Once an adapter for each framework is written, this

    approach is easier for everyone #phpworld
  64. A Symfony developer has found the solution for this

    approach… #phpworld
  65. None
  66. Puli: no longer just a unique looking dog breed

  67. None
  68. - Universal Packages for PHP #phpworld

  69. “Puli aims to replace specialized packages of different frameworks

    with one generic, framework independent solution.” #phpworld
  70. Puli, like Composer, has both a command-line tool and

    a JSON- based config file #phpworld
  71. Puli adds a layer on top of Composer, but

    doesn’t replace it #phpworld
  72. Puli packages are also Composer packages #phpworld

  73. Puli provides a naming convention to access non-PHP files

    from a Puli package #phpworld
  74. CSS, images, etc., are stored within the Puli package

    and mapped to their framework- specific locations #phpworld
  75. Puli packages can be both consumers and providers of

    resources and PHP classes #phpworld
  76. Learn more about Puli at or on Speakerdeck.

  77. Puli has a Symfony bundle/ bridge, allowing Puli packages

    to work out of the box with Symfony #phpworld
  78. Similar bridges are needed for other frameworks #phpworld

  79. Puli is the most developed attempt at solving the

    universal package problem in PHP #phpworld
  80. Puli isn’t perfect #phpworld

  81. Doesn’t handle frameworks that manipulate non-PHP config files directly

    on disk (I’m looking at you, Magento) #phpworld
  82. Hoping to spark a discussion and debate around universal

    packages for PHP #phpworld
  83. If Puli is the best approach, let’s get it

    integrated with our frameworks #phpworld
  84. Which takes us to… #phpworld

  85. Step 3: #phpworld

  86. None
  87. Change the community’s way of thinking #phpworld

  88. Start conversations at your local PHP user group about

    how much effort we currently duplicate #phpworld
  89. Start discussing the two different approaches to solving the

    problem #phpworld
  90. Introduce people to Puli & provide feedback on Github

    to the Puli project #phpworld
  91. Implement a Puli integration for your favorite framework #phpworld

  92. When you see someone duplicating effort by writing a

    framework-specific extension, tell them… #phpworld
  93. STOP IT! #phpworld

  94. Show them how to re-use an existing PHP package

    via Composer #phpworld
  95. Start your new projects as Composer packages, not application-specific

    extensions #phpworld
  96. Frameworks like Laravel have revolutionized the web by reducing

    the amount of time we waste writing boilerplate #phpworld
  97. Think about what we can do as a community

    if we stop duplicating each other’s work #phpworld
  98. Let’s start working together to solve new problems #phpworld

  99. We can change the web - and the world

  100. Keep in Touch! @JoshuaSWarren

  101. #phpworld