Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Composer From Zero To Hero

Composer From Zero To Hero

Slides of the workshop gave at WordCamp Torino 2018, about usage of Composer in WordPress plugin and websites.

Giuseppe Mazzapica

April 07, 2018

More Decks by Giuseppe Mazzapica

Other Decks in Programming


  1. PHP developer since 2005, first met WordPress in 2006. Moderator

    at wordpress.stackexchange.com Giuseppe Mazzapica Biggest German WordPress Agency WordPress.com Featured Service Partner Gold Certified WooCommerce Expert https://gmazzap.me @gmazzap github.com/gmazzap
  2. What we will do here today: Presentation Part 1: Intro

    to Composer. What, why, how. 20 min Hands-on 1: Your first Composer package 15 min Presentation Part 2: Composer and WordPress. The basics. 10 min Hands-on 2: Add Composer support to a plugin. 10 min Presentation Part 3: Composer and WordPress. Whole-site stacks. 5 min Hands-on 3: Write a whole-site Composer project for WordPress 20 min
  3. Composer is a tool for dependency management in PHP. It

    allows you to declare the libraries your project depends on and it will manage (install/update) them for you. https://getcomposer.org
  4. Reinventing the wheel is no good. How we can (re)

    use code in different projects? Copy and paste is not viable Git submodules are «unfriendly» and have issues ...and what about conflicts and incompatibilies? ...not to mention shareability and repeatability...
  5. Composer provides a simple and declarative way to define the

    project «dependency graph», taking care of «building» the project in affordable, shareable, and repeatable way preventing conflicts and incompatibilities. And that’s not all: It provides a convenient autoloader It provides scripting utilities It is written in PHP for PHP It is the de-facto industry standard
  6. Composer Concepts: Package Every project is a package. As soon

    as a directory has a , that directory composer.json is a package. Every project has «versions» and might have «dependencies», which are other packages. When a projects requires another package, there’s a «link» between them. The link is made of a source package, a target package, and a version constraint.
  7. Composer Concepts: Package The root package is the package defined

    by the at the root of the project. composer.json It is the main that defines the project composer.json requirements. Certain package properties are relevant when in the root package context. Every package can be used as root package, or as a dependency of other packages.
  8. Composer Concepts: Versions, Constraints and Links In the vast majority

    of cases packages are managed using a version control system like git, svn, hg or fossil. A «tag» in VCS is considered a stable version in Composer, a «branch» in VCS is considered a development version of the package. Composer infers packages version from VCS systems (even if there are way to set version manually).
  9. The part, that's often referred to casually as a version

    is 1.0.* actually more specifically a version constraint. A link between two packages is created in Composer by adding in a package a pointer to another composer.json package that looks like: Composer Concepts: Versions and Constraints and Links some-vendor/some-package": "1.0.*"
  10. A version constraint represent a set of versions of the

    target package that the source package want to link to. Composer Concepts: Versions, Constraints and Links Composer supports different ways to define constraint: Exact version 1.0.15 Version range >=1.0 >=1.0 <2.0 >=1.0 || >=1.2 Hyphenated Version Range 1.0 - 2.0 Wildcard Version Range 1.0.* 2.* * Caret Version Range ^1.1 Tilde Version Range ~1.1 ~1.2.1
  11. Composer supports different types of links. require and require-dev are

    the most common, but there’s also confict, replace, provide, and suggest. On installation/update Composers recursively resolves the the constraints of all the links declared by all the packages. Only if a set of packages that satisfies all constraints is found Composer proceeds by pulling packages. To pull packages, Composer needs to know where and how, and these information are provided by packages repositories. Composer Concepts: Versions, Constraints and Links
  12. Composer Concepts: Repositories Repositories are list of packages. For each

    package, the repository holds: the name (which usually is in the form vendor/name) the type (the most common and default is «library») a list of available versions, and for each version: an URL of the dist (which is in archive form) an URL of the source (which is the SVN URI) It is not required for repositories to hold both the dist and the source URL for packages, but one of them is required.
  13. Composer Concepts: Repositories Composer supports different types of repositories. The

    most common is the repository of type «composer». It takes the form of an URL to a packages.json file, which contains an array of packages information in JSON format. packagist.org is a repository of this type, it is the only repository that Composer uses by default. It is open and free for anyone to register packages which must be publicly accessible via a service like GitHub, BitBucket or GitLab.
  14. Composer Concepts: Repositories Other kind of repositories supported are: VCS

    Allows to use a VCS repository as Composer repository for a package. Useful for packages not available on packagist.org, or to use a fork of a package. Package Allows to define package informations manually. Useful for libraries that does not support Composer (don’t have a ). composer.json PEAR For packages available in any PEAR channel.
  15. Path To pull a single package from a local path.

    The package path is symlinked, so any edit on the source affects the requiring package withou the need of any update. Useful for development. Artifact A repository that consist in a local folder that contains any number of zip archives, each containing a package (with composer.json in the root folder). Composer Concepts: Repositories Other kind of repositories supported are:
  16. composer.json repositories* config* scripts* extra bin archive Others require require-dev*

    conflict replace provide suggest Package links name description type license authors version Metadata autoload autoload-dev* minimum-stability* prefer-stable* Autoload Stability
  17. Command Line Interface init install update require remove self-update create-project

    dump-autoload Must know Useful Others search show check-platform-reqs browse suggests status licenses exec diagnose archive global config validate help run-script outdated why why-not
  18. In this first hands-on we will write a Composer package

    which will print «developer quotes» from the command line. What you need: a local environment with: recent version of Composer git client an active internet connection 15min
  19. Composer For WordPress: Core WordPress core does not support Composer.

    All its dependencies are embedded in source code. Composer can however be used to install core: declaring as custom package using a custom repository that points to its source URL via unofficial packages like johnpbloch/wordpress-core
  20. Composer For WordPress: Plugins & Themes WordPress plugin and themes

    can be written with Composer support. «Composer Installers», an official Composer project, provides support for plugin and themes. The lack of core support bring many issues for users who want to use Composer; the most relevant are: the needs to often ship folder vendor the possibility of dependencies version conflicts
  21. Composer For WordPress: Plugins & Themes Plugin and themes with

    Composer support if publicly accessible on GitHub, BitBucket or Gitlab, can be added to packagist.org and installed via Composer. However, to make them available on official wp.org repository, they need to contain all the code of dependencies (the folder) which means the same library could be vendor added multiple times by different plugins. Which also means isses of version conflict among different versions of same library might arise.
  22. In this second hands-on we will see how a sample

    plugin that uses a 3rd party library can be edit to support Composer. This will be more a sort of «mob programming» where all attendees collaborates in editing the plugin, but the actual coding with be done on the presenter machine. 10min What you need: don’t forget to bring your brain
  23. Composer For WordPress: The whole website stack The only reliable

    way to let Composer do its job, and avoid conflicts and other issues is to use it to manage the dependency graph of all the website, having a single vendor folder for all the dependencies. For plugins and themes be compatible with this approach a little extra care is required in the development.
  24. Composer For WordPress: The whole website stack The lack of

    Composer support of core caused the proliferation of various 3rd party, unofficial services and libraries which are commonly used to ease the WordPress-Composer integration. Worth a mention: wpackagist.org wp-languages.github.io roots.io/bedrock wecodemore.github.io/wpstarter
  25. In this third and last hands-on we will write a

    Composer project to manage a whole site, including core, plugins and themes. What you need: a local environment with: recent version of Composer git client an active internet connection 20min a webserver to test the site on the browser