Php Dependency Management with Composer ZendCon 2016

© 2016 Rogue Wave Software, Inc. All Rights Reserved. 1
PHP Dependency
Management with
Composer
Clark Everetts
Sr. Professional Services Consultant
18 October 2016

Slides, Joind.in, and Stuff
• Rate & comment: https://joind.in/talk/04872
• Slides: https://www.slideshare.net/clarkphp
• Tweets: #ZendCon2016
• @clarkphp

Why are we here? Our Agenda
• What is it? What problem does it solve?
• What does it actually do?
• Composer.json & composer.lock
• Semantic Versioning, Version Constraints
• Packages, Repositories and Packagist
• Do’s and Don’ts / Best Practices
• Create a Private Repository
Cool logo!

Assumption: You’ve seen JSON
(JavaScript Object Notation)
Jason is scary.
JSON is not.
*https://en.wikipedia.org/wiki/Jason_Voorhees

INTRODUCTION/
BACKGROUND

Composer is …
… a per-project PHP
dependency
manager*
*(plus autoloader)
That’s all.
Any questions?

… a per-project
PHP
dependency
manager
Let’s break it down.
Composer is …
* Paraphrased from
https://getcomposer.org/doc/00-intro.md

PHP Package Dependencies
… a per-project PHP dependency manager
• PHP project-related files only
• Can include assets like Javascript, images, XML, CSS, etc.
• But not for managing Javascript or CSS libraries
• Primarily a development - not production – tool (“can” be prod*)
*but generally,
I’m not a fan

What’s a “dependency?”
You wrote these to
reuse across apps.
3rd-Party
ZF2, Laravel, OAuth2,
Symfony
Your Project
DEPENDENCIES,
PACKAGES,
LIBRARIES
“Project” == Application

Dependencies can have dependencies
Your Project “Project” == Application == Library == Package
DEPENDENCIES,
PACKAGES,
LIBRARIES
“I need
A, B, C, D”
A B C D
“I need
E” E F
“I need
E”
Composer obtains all
specified dependencies.
HG
“I need G,
H”

Want to manage that yourself?
“I need these”
“I need
this”
A B C
E
D
F
G H
“I
need
that”
“I need the
other”
You’d need to:
• Identify the direct dependencies of your project
• Identify their dependencies, and all sub-dependencies
• Locate the source code (PEAR, Git, Subversion, zip/gzip/bz2)
• Download and install all of the source code
• Make sure all the versions are compatible
• Check for updates to any of the dependencies
• Do it all again when updates are available
With your guidance,
Composer does all
this for you.

Different versions of the same package
Application
A
Application
B
Lib Y
1.0.1
Lib X
2.4.1
Lib Y
1.0.1
Lib X
1.2.0
Two projects, each using a
different version of the same
dependencies.
Composer is not a global
“package manager”
PEAR, APT, YUM,
Include_path
Why do this?
• Application A is stable, new features or bug fixes not relevant
• Working with development version: Dev, Alpha, Beta, RC
• Update cycle for App A !== App B

To Reiterate: per-project; not global
Application
A
Application
B
Lib Y
1.0.1
Lib X
2.4.1
Lib Y
1.0.1
Lib X
2.4.1
Two projects, each using
same version of the same
dependencies.
Each project has it’s own copy.
• Like a PHAR (PHP Archive) file, all dependencies are available in the application
directory tree.
• Updates to the dependencies of one application do not affect another.
• .gitattribute notwithstanding, potentially many copies of the exact same library
source code on disk.

Composer is…
• Knows what packages your application or library
depends upon
• Obtains those packages, and all of their
dependencies, and installs appropriate versions of
them into your project (and local cache)
• When requested, checks for updates compatible
with your project, and downloads them into your
project (and local cache)
• Allows you to pin multiple applications/libraries to
the same or different versions of the packages they
use.
Composer makes it
easier to manage
application
dependencies.

Now What?
Answered some questions, raised others:
• How do we inform Composer what dependencies a
project has?
– composer.json, composer.lock
• Where does it put the dependencies in the project?
– vendor folder
• Where does Composer obtain dependencies?
– repositories
• How does the project access to those
dependencies when it needs them?
– autoloading
• How do we install Composer and start using it?
A closer look…

INSTALL COMPOSER

Installation
• Windows
– https://getcomposer.org/Composer-Setup.exe
– https://getcomposer.org/doc/00-intro.md#installation-windows
– Or, GitBash, and follow *nix instructions
• *nix and IBM i PASE
– https://getcomposer.org/doc/00-intro.md#installation-linux-unix-osx
– Command line instructions on https://getcomposer.org/download/
• Manual Download on same page https://getcomposer.org/download/
• IBM i
– CALL QP2TERM (or ssh)
– Before installing, check KB article:
– https://support.zend.com/hc/en-us/articles/205679027-Add-a-trusted-
certificate-authority-to-IBM-i-for-PHP-5-6 (though I think downloading via
browser from https://curl.haxx.se/docs/caextract.html is better)
• Once installed, updates are easy:
– $ composer self-update

Help is available
• Get help
– $ composer help (top-level help)
– $ composer list (list available commands)
– $ composer help <command> (help on specified command)
• Documentation
– https://getcomposer.org/doc/01-basic-usage.md
– https://getcomposer.org/doc/03-cli.md (command line interface)

COMPOSER.JSON &
COMPOSER.LOCK

General Tips
• Don’t edit composer.json files. Use the command line tooling!
– $ composer require zendframework/zend-mvc
• Add require entry for the component, specifying the latest stable release that does not
conflict with other requirements
– $ composer require --dev phpunit/phpunit
• Specify development requirements (libraries needed to edit/test the dependency)
– $ composer require --update-no-dev monolog/monolog
• Add package, with no dev dependencies (we’re consuming only, not developing/testing)
– $ composer require "zendframework/zend-mvc:^2.5"
• Specify constraints
– $ composer require "zendframework/zend-mvc:^3.0@dev"
• Specify stability requirements
– $ composer remove zendframework/filp-whoops
• Remove a package; use --update-no-dev to avoid installing all require-dev
dependencies after the removal!
• Benefit: these do the install/update automatically, (generally) ensuring the update is only for the
package specified; unrelated dependencies are left alone. Faster and no unnecessary changes.

Describing Project Dependencies
composer.json file tells Composer about your project’s needs
Composer-Intro
zendframework/
zend-log
>=2.8.0
{
"name" : "Composer-Intro",
"require" : {
"zendframework/zend-log" : “>=2.8.0"
},
"repositories" : [ {
"type" : "composer",
"url" : "https://packagist.org/"
} ]
}
>= is an unbound version constraint,
a general no-no, used here for
illustration only
composer.json
composer.json
? ? ?
Not necessary to edit composer.json manually! Best practice is to use command line!
composer init, composer require, composer remove

Installing Project Dependencies
First Level (Direct) Deps
composer install
Composer-Intro
zendframework/
zend-log
>=2.8.0
New:
•Vendor Directory
•composer.lock file
AfterBefore
{
"require" : {
"zendframework/zend-log" : “>=2.8.0"
}
}

Further Levels (1 of 3)
zend-log composer.json file contains this:
{ …
"require": {
"php": "^5.5 || ^7.0",
"zendframework/zend-servicemanager": "^2.7.5 || ^3.0.3",
"zendframework/zend-stdlib": "^2.7 || ^3.0",
"psr/log": "^1.0",
},
…
}
zend-log needs three more packages

zend-stdlib:
{ …
"require": {
"php": "^5.6 || ^7.0"
},
…
}
No further code dependencies
Only PHP constraint (platform package)
zend-servicemanager:
{ …
"require": {
"php": “^5.5 || ^7.0",
“container-interop/container-interop”: “~1.0”
},
…
}
psr-log:
{ …
"require": {
"php": “>=5.3.0"
},
…
}
Still need more

No further code dependencies
container-interop:
{
"name": "container-interop/container-interop",
"type": "library",
"description": "Promoting the interoperability of container objects (DIC, SL, etc.)",
"license": "MIT",
"autoload": {
"psr-4": {
"InteropContainer": "src/Interop/Container/"
}
}
}

Where dependencies are stored by default
Application
vendor
zend-stdlib
zend-log
Dependency
Relationship
zend-servicemanager
Application
Directory
Structure
zend-log
zend-servicemanager
zend-stdlib
psr/log
container-interop
container-interop
psr/log

.json vs. .lock
Think “Design-To” vs. “As-Built”
Application
zendframework/
zend-log
>=2.8.0
composer.json tells Composer
what you want
composer.lock tells you
what you got
Application
zend-
stdlib
3.1.0
zend-log
2.9.1
zend-
servicemanager
3.1.1
psr/log
1.0.2
container-iterop
1.1.0

“Design-To” vs. “As-Built” Further Example
Application
Composer resolves versions as best it can
actual versions installed recorded in composer.lock
Application
zendframework/
zend-log
>=2.5,<2.7
zend-
stdlib
2.7.7
zend-log
2.6.0
zend-
servicemanager
2.7.7
psr/log
1.0.2
container-iterop
1.1.0
zend-hydrator
1.1.0

Problems Can Occur
Your Project
“I need E
>=1.0,<1.2”
A B C
E version ?
“I need E
>=1.2,<2.0”

SEMANTIC VERSIONING
&
COMPOSER VERSION
CONSTRAINTS

Semantic Versioning http://semver.org/
Version Numbers Have Meaning
• Essentially, it is a promise from the development team
• Not a guarantee, but best effort
• 1.2.3 – numbers increment, can have pre-release suffix
• Major.Minor.Patch
• Patch: bug fixes; no BC breaks! No API changes! Everyone using
the package should be confident in moving from 1.2.3 to 1.2.4
• Minor: introduce new features, but change no prior APIs; no BC
breaks! Changing internals (refactoring) should not affect
package users. Everyone using the package should be confident in
moving from 1.2.3 to 1.3.0.
• Major: API changes; BC breaks (whether intentional or not).
Example: 1.3.14 to 2.0.0
• For developers, not marketing department. (Sorry, Marketing!)

Version Number ChangesImplication for Developers
• 0.1.0 #’s change as you see fit,• Initial Development / API Not Stable
• 0.1.1 as long as major # is zero• Public API remains Unstable
• …• …
• 1.0.0• Public API Declared Stable
• 1.0.1 only patch # incremented• Backwards-Compatible Bugfix
• 1.0.2• BC Bugfix
• …• …
• 1.1.0 minor # incremented, patch # reset to zero• New BC Featureor deprecation (API change)
• 1.1.1• BC Bugfix
• …• …
• 2.0.0 major # incremented, minor/patch reset to zero• Any BC Break to Public API
• 2.0.1 only patch # incremented• BC Bugfix

MeaningPre-Release Versions & Build Metadata
• Not Stable, might not be compatible as implied
by “normal” version number
• Format: x.y.z-alpha-nums.alpha-nums
• Precedence / Ordering
• 1.0.0-alpha < 1.0.0
• 1.3.0-alpha < 1.3.0-beta
• 1.3.0-rc < 1.3.0-rc.1
• 2.0.0-rc.1 < 2.0.0-rc.11
• 2.1.0-0.2.2 < 2.1.0-0.2.2.a
• Pre-Release Examples
• 1.0.0-alpha
• 1.3.0-beta
• 1.3.0-rc
• 2.0.0-rc.1
• 2.1.0-0.2.2
• Information about the build
• Ignored in precedence comparison
• 1.0.0+001 === 1.0.0+alpha-20161018122346
• Build Metadata
• Format: x.y.z+alpha-nums
• 1.0.0+001
• 1.0.0+alpha-20161018122346

Semantic Versioning and Composer
Version Constraints
Shortcut notations for version constraints
Caret
• ^1.2.3 is same as >=1.2.3,<2.0.0 and means 1.2.3 <= x < 2.0.0
• Specifies a min version, and all non API-changing updates
• Recommended operator for max interoperability of library code
Tilde (updates in the same series as the rightmost digit*)
• ~1.2.3 is same as >=1.2.3,<1.3.0 and means 1.2.3 <= x < 1.3.0
• Specifies a min version; last number specified can increment
• For this example, we accept only bug-fixes, no new features.
• ~1.2 is same as >=1.2.0,<2.0.0 and means 1.2.0 <= x < 2.0.0
• For this example, we accept all non-breaking changes
• https://getcomposer.org/doc/articles/versions.md *How Matthew
https://mwop.net/
likes to think of it.
Comma or space:
logical and

Practice: Semver Version Constraints
What range is specified by:
• ^2.0.3 is same as ?
• ~2.0.3 is same as ?
• ^3.7.0 is same as ?
• ~3.7.0 is same as ?
• ^4.4 is same as ?
• ~4.4 is same as ?
• ^3 is same as ?
• ~3 is same as ?
Try out the Semver Checker
http://semver.mwl.be/
>=2.0.3,<3.0.0 means 2.0.3 <= x < 3.0.0
>=2.0.3,<2.1.0 means 2.0.3 <= x < 2.1.0
>=3.7.0,<4.0.0 means 3.7.0 <= x < 4.0.0
>=3.7.0,<3.8.0 means 3.7.0 <= x < 3.8.0
>=4.4.0,<5.0.0 means 4.4.0 <= x < 5.0.0
>=4.4.0,<5.0.0 means 4.4.0 <= x < 5.0.0
>=3.0.0,<4.0.0 means 3.0.0 <= x < 4.0.0
>=3.0.0,<4.0.0 means 3.0.0 <= x < 4.0.0

Other Composer Version Constraints
Range Operators
• And - comma or space:
• “>=1.2.3,<2.0.0” means 1.2.3 <= x < 2.0.0
• Or – vertical pipes:
• “^2.7.5 || ^3.0.3” means
• >=2.7.5,<3.0.0 || 3.0.3,<4.0.0
• 2.7.5 <= x < 3.0.0 or 3.0.3 <= x < 4.0.0
• <, <=, >, >=, != Best practice: avoid unbound constraints like ”>=1.2.3”
• For great examples, see
https://github.com/Roave/SecurityAdvisories/blob/master/composer.json
• Hyphen
• 1.0-2.0 is same as >=1.0.0,<2.1.0 and means 1.0.0 <= x < 2.1.0
• 1.0.0-2.1.0 is same as >=1.0.0,<=2.1.0 and means 1.0.0 <= x <= 2.1.0
• Wildcards (generally avoid for performance reasonse): 1.0.* I
• same as >=1.0.0,<1.1.0 and means 1.0.0 <= x < 1.1.0

REPOSITORIES-lite

Where do dependencies come from?
1. Read
Your
Application
composer.json
Repository
(or cache*)
2. Resolve dependencies &
obtain packages from
code repository (ies)
composer.lock
vendor
folder
4. Create
Initial composer install
With no composer.lock
Composer will …
*Aggressive caching
• Fast installs
• Reduced network fetch

Initial composer install
1. Read
Your
Application
composer.json
Repository
(or cache*)
2. Resolve dependencies &
Obtain packages from
composer.lock
vendor
folder
4. Create
With no composer.lock
Composer will …
*Aggressive caching
• Fast installs
• Reduced network fetch

Subsequent composer install
1. Read
Your
Application
composer.json
Repository
(or cache)
3. Write packages into
composer.lock
vendor
folder
With existing composer.lock
Composer will …
2. Obtain lock file versions from

Any composer update
1. Read
Your
Application
composer.json
Repository
(or cache)
composer.lock
vendor
folder
4. Update
Whether composer.lock
exists or not
Composer will … 2. Obtain packages’ latest
compatible release from

Development Considerations
Packagist.org,
Local repos
2. composer install
Development
Workstation /
Vhost
B
Development
Workstation /
Vhost
A
1. composer update &
commits to local VCS
General Best Practice: Always commit .lock file
• Allows synchronization between developers
• Helps ensure what was actually tested is what you deploy to production
Development
Workstation /
Vhost
C
install === “synchronize”

Production Considerations
Production
Server
Packagist.org
composer install
composer update
Please do NOT do this.

“Build”
Server
Packagist.org
composer install
with composer.lock file
Better.
Production
Server

Test
ServerBest
Production
Server
Local
Repository (VCS /
Change Mgt,
Packagist)
Production
Server
Or
Local
Repository (VCS /
Change Mgt,
Packagist)

PACKAGES & REPOSITORIES

What are Packages & Repositories?
Composer downloads packages from repositories
Package
• A directory with files in it
• Package description - composer.json
• Name (this is what makes a package an installable library)
• Version (avoid specifying this, inferred from VCS info)
• Source Definition (where Composer gets the package)
• Repository location (URI)
• Repository Type (composer, vcs, pear, package)
• Package Type
• Dist – packaged, usually a stable release
• Source – source code, for development / modification
• Repo can provide both, but one will be preferred

Package Names
• vendor-name/project-or-library-name
• psr/log
• pear/log
• zendframework/log
• Best practice: use-dashes/as-word-separators
• Vendor names must be unique
• If you are going to publish packages:
• Remember: they persist! You and the world will have to live with them.
• Don’t be cute or cryptic (with vendor or package name)
• Name should reflect package purpose
• evandotpro/edp-superluminal - I like it, clever, but…

Platform / Virtual Packages
Not Installable by Composer, Used for checking only
• php – PHP version of the server Composer is installing packages to
• hhvm (not applicable for IBM i)
• ext-<name>
• “ext-ibm_db2” : “*”
• lib-<name>
• curl
• iconv
• icu
• libxml
• openssl
• pcre
• uuid
• xsl
• composer show --platform for a list of available platform packages

Repositories
Repository
• A download source for packages, specified by URI
• A list of packages and versions in a packages.json file
• Visit https://packagist.org/packages.json
• Types of repositories
• Composer – uses Packagist software, can public or private
• VCS – Git, SVN, Hg
• VCS client needed for “regular” git, svn, or hg repos
• Uses APIs for GitHub, BitBucket (no client needed)
• PEAR – public or private
• Package – zip; use only if none of the above are possible

Repositories: Packagist.org
Packagist.org Package Archivist
Just a Composer Repository…
• … but it is the primary repository for open source packages
• Best Practice for Open Source Projects: register it at packagist.org
• Searchable / Browsable
• Less work for people to find and use your package.
• Many, many, many packages available. There is duplication in
functionality and a wide range of quality. (Important topic for
another day.)

https://packagist.org/

Private Repositories – Satis and Toran Proxy
Your
Application
Packagist.org
Proxy
Toran /
Satis
Public
Repositories
Satis – free
ToranProxy.com – license
fees support development
of Composer
Why?
• Speed.
• Happier network
security staff.

Private Repositories – Local Packagist
Your Application
composer.json /
composer.lock
Private
Repository

Not-Final Word on Repositories
We will create and use a private
repository in part two of today’s tutorial

COMPOSER BEST PRACTICES

Some Best Practices
Do’s and Don’ts:
• Command line tooling is your friend
• Building a deployment fileset with
Composer
• Unbound Version Constraints
• Version Constraints combined with
Wildcards
• Wildcards by themselves
• Install or update to the intended directory
Be careful
out there!

Command line tooling
• Don’t edit composer.json files. Use the command line tooling!
– $ composer require zendframework/zend-mvc
• Add require entry for the component, specifying the latest stable release that does not
conflict with other requirements
– $ composer require --dev phpunit/phpunit
• Specify development requirements (libraries needed to edit/test the dependency)
– $ composer require --update-no-dev monolog/monolog
• Add package, with no dev dependencies (we’re consuming only, not developing/testing)
– $ composer require "zendframework/zend-mvc:^2.5"
• Specify constraints
– $ composer require "zendframework/zend-mvc:^3.0@dev"
• Specify stability requirements
– $ composer remove zendframework/filp-whoops
• Remove a package; use --update-no-dev to avoid installing all require-dev
dependencies after the removal!
• Benefit: these do the install/update automatically, (generally) ensuring the update is only for the
package specified; unrelated dependencies are left alone. Faster and no unnecessary changes.

Don’t install
development requirements
Use lock file
Download Distribution
Packages
composer install - - prefer-dist - - no-dev - - optimize-autoloader
Generate PSR-0/4 classmap
for fast autoloading
Building Deployment Filesets

Do NOT use unbound version
constraints (>=, no upper bound):
• Example: >=2.3
• Example: >=1.1.* (note that * is not
the problem here, >= is)
• Composer will install new updates,
as long as they become available,
without regard to backwards-
compatibility. (You’ll get 2.3.5,
10.5.23, etc.)
• Example: dev-master
Best Practice
Use ^2.3
Use ^1.1
Best Practices Do’s and Don’ts
Solution: >=2.3,<3.0 or ~2.3 or ^2.3
Solution: >=1.1.0,<1.2 or ~1.1.0

Do NOT attempt to specify a version
constraint with a wildcard:
• Example: >=2.*
• >=2 means any version at least 2.0.0
• (2.0.5, or 2.9.9, or 3.0.7, 10.3.2, etc.)
• 2.* means any version in the interval
• [2.0.0, 3.0.0), or 2.0.0-2.9.9999
• Composer can’t tell if you want 3.0.0
to be considered, or not.
Composer: “Invalid, I’m
throwing an error”
Solution: use >=2,<3
Best Practice:
^2 (for semantic versioning)

Do NOT use a wildcard (except
for virtual extension packages)
• Example: 1.2.* is bad –
slows composer down
• Looks at all patch level
releases, and all their sub-
dependencies
• Also limits composer to
versions < 1.3 forever
Composer: “Don’t make me work so hard!”
Solution:
(if you really want < 1.3) use ~1.2.0 or
>=1.2.0,<1.3
or
(if you really want >= 1.2)
use ~1.2.0 or >=1.2.0,<2.0.0
or
SemVer Best Practice:
^1.2

• Make SURE you’re in the right
folder when issuing composer
install
• Will read composer.json in that
folder, create vendor folder, and
.lock file
• Regardless of existence of .lock
file in project root directory
• Same for composer update!
• Part of your vendor folder
could be updated with
packages not compatible
with other packages
Run composer install /update
from root of your project.

PART DEUX:
PRIVATE REPOSITORY

Setting up a Private Composer Repo
• Satis Private Repository Needs
– VCS repository containing our package
– Install Satis
– Make Satis aware of our VCS repository
– Use Satis to build the composer repository
– Host the repository via web server (demo using PHP built-in server)
– Configure an application to use our package
– Test it!

VCS Repository of Source Code
clark.e@US-114-carle MINGW64 ~/Zend/workspaces/Talks/measurement (master)
$ ls -l
total 67
-rw-r--r-- 1 clark.e 1049089 233 Oct 18 09:41 CHANGELOG.md
-rw-r--r-- 1 clark.e 1049089 917 Oct 18 09:48 composer.json
-rw-r--r-- 1 clark.e 1049089 36864 Dec 30 2015 composer.lock
-rw-r--r-- 1 clark.e 1049089 209 Oct 18 09:49 deployment.properties
-rw-r--r-- 1 clark.e 1049089 381 Apr 13 2016 deployment.xml
drwxr-xr-x 1 clark.e 1049089 0 Dec 27 2015 doc/
-rw-r--r-- 1 clark.e 1049089 157 Jan 1 2016 FAQ.md
-rw-r--r-- 1 clark.e 1049089 6 Dec 26 2015 index.php
-rw-r--r-- 1 clark.e 1049089 2508 Oct 18 09:48 LICENSE.txt
-rw-r--r-- 1 clark.e 1049089 564 Jan 1 2016 phpunit.xml
-rw-r--r-- 1 clark.e 1049089 569 Dec 26 2015 phpunit.xml.dist
drwxr-xr-x 1 clark.e 1049089 0 Jan 1 2016 src/
drwxr-xr-x 1 clark.e 1049089 0 Jan 1 2016 test/
drwxr-xr-x 1 clark.e 1049089 0 Dec 30 2015 vendor/

Install Satis
$ cd ~
$ composer create-project --stability=dev --keep-vcs composer/satis satis
$ cd ~/satis/bin
$ php satis
• Satis version 1.0.0-dev
• Usage:
• command [options] [arguments]
• Options:
• -h, --help Display this help message
• -q, --quiet Do not output any message
• -V, --version Display this application version
• --ansi Force ANSI output
• --no-ansi Disable ANSI output
• -n, --no-interaction Do not ask any interactive question
• -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
• Available commands:
• add Add repository URL to satis JSON file
• build Builds a composer repository out of a json file
• help Displays help for a command

Make Satis Aware of our VCS Repo
$ cd ~/satis-repo
$ ../satis/bin/satis init
Welcome to the Satis config generator
This command will guide you through creating your Satis config.
Repository name: Demo Satis Repo
Home page: http://localhost:8000
Your configuration file successfully created!
You are ready to add your package repositories
Use satis add repository-url to add them.
$ cat satis.json
{
"name": "Demo Satis Repo",
"homepage": "http://localhost:8000",
"repositories": [],
"require-all": true
}

$ ../satis/bin/satis add "file:///c/Users/clark.e/Zend/workspaces/Talks/measurement/.git"
Your configuration file successfully updated! It's time to rebuild your repository
$ cat satis.json
{
"name": "Demo Satis Repo",
"homepage": "http://localhost:8000",
"repositories": [
{
"type": "vcs",
"url": "file:///c/Users/clark.e/Zend/workspaces/Talks/measurement/.git"
}
],
"require-all": true
}

$ ../satis/bin/satis build satis.json .
Scanning packages
wrote packages to ./include/all$a95d2027bae57a0d1bb43d5aa4dc7b48cd8b99cd.json
Writing packages.json
Pruning include directories
Writing web view
$ ls -al
total 358
drwxr-xr-x 1 clark.e 1049089 0 Oct 18 10:45 ./
drwxr-xr-x 1 clark.e 1049089 0 Oct 18 10:38 ../
drwxr-xr-x 1 clark.e 1049089 0 Oct 18 10:45 include/
-rw-r--r-- 1 clark.e 1049089 291385 Oct 18 10:45 index.html
-rw-r--r-- 1 clark.e 1049089 192 Oct 18 10:45 packages.json
-rw-r--r-- 1 clark.e 1049089 263 Oct 18 10:38 satis.json

Host Composer Repo via Webserver
$ php -S localhost:8000

Configure Application to Use Package
$ cd ~/test-app/
$ ls -al
total 65
drwxr-xr-x 1 clark.e 1049089 0 Oct 18 09:34 ./
drwxr-xr-x 1 clark.e 1049089 0 Oct 18 11:02 ../
-rw-r--r-- 1 clark.e 1049089 383 Oct 18 09:34 example-usage.php
$ cat composer.json
{
"repositories": [ { "type": "composer", "url": "http://localhost:8000" } ]
}

Resources
• Composer Manual - https://getcomposer.org/doc/
• Semantic Versioning - http://semver.org/
• Autoloading - http://www.php-fig.org/psr/psr-4/
• JSON (JavaScript Object Notation) - http://json.org/
• Help - https://groups.google.com/forum/#!forum/composer-users
• IRC - #composer on freenode irc://irc.freenode.org/composer
• Packagist Semver Checker – http://semver.mwl.be/
• Composer.json Schema
– https://getcomposer.org/doc/04-schema.md
– https://github.com/composer/composer/blob/master/res/compo
ser-schema.json
– http://stackoverflow.com/questions/tagged/composer-php

So who is this guy?
Clark Everetts, ZCE
• Rogue Wave Software (acquired Zend 1 year ago)
• PHP since 2005
• Professional Services Consultant
– Architecture and Performance Audits
– PHP, Zend Framework Training
– Application Development, Best Practices, etc.
• clark.everetts@roguewave.com @clarkphp +ClarkEveretts

THANK-YOU
clark.e@roguewave.com
@clarkphp
+ClarkEveretts
Slides for this talk are
at the above Joind.in link
Tweets: #ZendCon2016
Rate & comment on this session
https://joind.in/talk/04872
Your feedback is invaluable!

Php Dependency Management with Composer ZendCon 2016

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Php Dependency Management with Composer ZendCon 2016

Ähnlich wie Php Dependency Management with Composer ZendCon 2016 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Php Dependency Management with Composer ZendCon 2016