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
Tweet

More Decks by Giuseppe Mazzapica

Other Decks in Programming

Transcript

  1. Composer
    from
    Zero to
    Hero
    Giuseppe Mazzapica
    WORKSHOP

    View Slide

  2. 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

    View Slide

  3. 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

    View Slide

  4. Introduction to Composer

    View Slide

  5. 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

    View Slide

  6. 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...

    View Slide

  7. 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

    View Slide

  8. 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.

    View Slide

  9. 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.

    View Slide

  10. 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).

    View Slide

  11. 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.*"

    View Slide

  12. 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

    View Slide

  13. 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

    View Slide

  14. 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.

    View Slide

  15. 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.

    View Slide

  16. 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.

    View Slide

  17. 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:

    View Slide

  18. 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

    View Slide

  19. 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

    View Slide

  20. Hands-On 1
    Your first Composer package

    View Slide

  21. 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

    View Slide

  22. Composer & WordPress

    View Slide

  23. 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

    View Slide

  24. 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

    View Slide

  25. 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.

    View Slide

  26. Hands-On 2
    Add Composer support to a plugin

    View Slide

  27. 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

    View Slide

  28. Whole-site WordPress
    projects with Composer

    View Slide

  29. 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.

    View Slide

  30. 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

    View Slide

  31. Hands-On 3
    A whole-site Composer project

    View Slide

  32. 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

    View Slide

  33. Thanks to for being here.
    ASK ME ANYTHING

    View Slide