6. Third Party Code
● Helps us to build software projects more quickly.
● Increase reusability.
● Large scale application couldn't be built without the use of the
well-maintained third-party libraries.
7. Dependency
The benefits of software reuse come
with a cost.
● We use certain third party libraries to speed
up development and reuse already written
piece of code.
● So our code directly depend of some of the
third party libraries without that our code will
not work.
● Those direct libraries can further depends on
other third party libraries….and so on...
● This hierarchical behaviour of dependent
libraries is called Dependency Tree & way to
manage it called Dependency Management.
● Dependency Management Way:
○ Manual
○ Automated
9. Manual
● Search for require library in package repositories list.
● Check it dependencies and find out available versions if any.
● Check version specific backward compatibility.
● Repeat steps for each and every library we need.
● Most of the time, third party library added as part of project in repository,
unnecessarily increasing project code size.
● Sometime we start new project by using same old library without
considering upgradation of it.
● Manually check for its update and security check along with backward
compatibility.
11. PEARPHP Extension and Application
Repository.
● It has set of libraries, which programmers
can contribute to it.
● It includes command-line tools for
managing third party libraries along with
their dependencies.
● For a long time, it was the best approach
and was used by many, but it also has
shortcomings.
●
12. PEARPHP Extension and Application
Repository.
● PEAR library installations are stored globally
on the operating system.
● Its very important to know exactly which
library versions are running on any given
system.
● What if system don’t have required version
of library?
● The amount of efforts and risk involved in
either upgrading or degrading given library
version.
● It can be good with dedicated host, but what
if shared hosting is involved.
● So needs of better tool emerge.
13. Composer
PHP Dependency Manager
● In April 2011, Nils Adermann and Jordi
Boggiano, decided & began working it.
● They released Composer on March 1, 2012.
● We can create a configuration file
(composer.json) specifying the third-party
libraries along with their version.
● They created command line tool called
composer.
● Composer downloads all the libraries locally
(by default project wise) that we specified
along with their dependencies.
● It also provided various set of commands
which helps us to manage the
dependencies.
16. Composer Schema
● Name
○ The name of the package.
○ It consists of vendor name and project name, separated by ‘/’.
○ It can contain any character, including white spaces (white space is not advisable)
○ It is case insensitive
○ symfony/framework-standard-edition
● License
○ The license of the package.
○ This can be either a string or an array of strings.
○ Apache-2.0, BSD-2-Clause, BSD-3-Clause, LGPL-2.1, MIT, etc
○ For closed-source software, you may use "proprietary".
17. Composer Schema
● authors
○ name: The author's name. Usually their real name.
○ email: The author's email address.
○ homepage: An URL to the author's website.
○ role: The author's role in the project (e.g. developer or translator)
● Type
○ The type of the package.
○ project, library, metapackage, composer-plugin, custom type
○ It defaults to library
● Keywords:
○ An array of keywords that the package is related to.
18. Composer Schema
● description
○ Short description of the package. Required for published packages.
● autoload
○ Autoload mapping for a PHP autoloader.
○ psr-0, psr-4,
19. Composer Schema
● version:
○ Semantic Versioning
■ Given a version number MAJOR.MINOR.PATCH, increment the:
■ MAJOR version when you make incompatible API changes,
■ MINOR version when you add functionality in a backwards-compatible manner, and
■ PATCH version when you make backwards-compatible bug fixes.
20. Composer Schema
● version:
○ Exact
■ This will tell Composer to install this version and this version only.
■ If other dependencies require a different version, the solver will fail and abort install
or update procedures.
■ example: 1.0.2, 2.0.2
○ Range
■ We can use comparison operators to specify ranges versions.
■ Operators are >, >=, <, <=, !=.
■ space ( ) or comma (,) as a logical AND.
■ double pipe (||) as a logical OR.
■ AND has higher precedence than OR.
21. Composer Schema
● version:
○ Range Continue...
■ >=1.
■ >=1.0 <2.0
■ >=1.0 <1.1 || >=1.2
○ Range (Hyphen)
■ 1.0 - 2.0 is equivalent to >=1.0.0 <2.1
■ 1.0.0 - 2.1.0 is equivalent to >=1.0.0 <=2.1.0.
22. Composer Schema
● version:
○ Tilde
■ ~1.2 is equivalent to >=1.2 <2.0.0,
■ ~1.2.3 is equivalent to >=1.2.3 <1.3.0
■ To mark the minimum minor version for a package
■ It specifies a minimum version, but allows the last digit specified to go up.
○ Caret
■ ^1.2.3 is equivalent to >=1.2.3 <2.0.0
■ It always allow non-breaking updates, it should not break backwards compatibility
23. Composer Schema
● require:
○ Lists packages required.
○ Package names with version.
○ It also support stability flags,
○ The stability flags allow to further restrict or expand the stability of a package beyond the
scope of the minimum-stability setting.
○ If one of your dependencies has a dependency on an unstable package you need to
explicitly require it as well, along with its sufficient stability flag.
○ Available options are dev, alpha, beta, RC, and stable.
25. Validate
● # php composer.phar validate
● It validate the composer.json file.
● Always run the validate command before you commit your composer.json
file, and before you tag a release.
● It has options
○ no-check-all, no-check-lock, no-check-publish, with-dependencies, strict
26. Outdated
● # php composer.phar outdated
● It shows a list of installed packages that have updates available, including
their current and latest versions.
● It has options:
○ --all (-a): Show all packages, not just outdated (alias for composer show -l).
○ --direct (-D): Restricts the list of packages to your direct dependencies.
○ --strict: Returns non-zero exit code if any package is outdated.
○ --minor-only (-m): Only shows packages that have minor SemVer-compatible updates.
○ --format (-f): Lets you pick between text (default) or json output format.
27. Outdated
● The output color coding is as such:
○ Green: Dependency is in the latest version and is up to date.
○ Yellow: Dependency has a new version available that includes backwards compatibility
breaks according to semver, so upgrade when you can but it may involve work.
○ Red: Dependency has a new version that is semver-compatible and you should upgrade it.
28. Prohibits
● #php composer.phar prohibits <package_name> <version>
● Check the compatibility of a given package with already installed
packages.
● It help us to find which packages are blocking a given package from being
installed.
#php composer.phar prohibits symfony/symfony 3.1
laravel/framework v5.2.16 requires symfony/var-dumper (2.8.*|3.0.*)
29. Prohibits Continue...
● #php composer.phar prohibits php:<version>
● We can also specify platform requirements
● For example to check whether we can upgrade our server to PHP 8.0:
○ #php composer.phar prohibits php:8
○ doctrine/cache v1.6.0 requires php (~5.5|~7.0)
○
○ doctrine/common v2.6.1 requires php (~5.5|~7.0)
○ Doc
● Options:
○ --recursive (-r): Recursively resolves up to the root package.
○ --tree (-t): Prints the results as a nested tree, implies -r.
#php composer.phar prohibits php:8
doctrine/cache v1.6.0 requires php (~5.5|~7.0)
doctrine/common v2.6.1 requires php (~5.5|~7.0)
doctrine/instantiator 1.0.5 requires php (>=5.3,<8.0-DEV)
30. Depends
● #php composer.phar depends <package_name> <version>
● It help us to find out all indirect dependencies of a given package.
● Options
○ --recursive (-r): Recursively resolves up to the root package.
○ --tree (-t): Prints the results as a nested tree, implies -r.
#php composer.phar depends doctrine/lexer
doctrine/annotations v1.2.7 requires doctrine/lexer (1.*)
doctrine/common v2.6.1 requires doctrine/lexer (1.*)
31. Depends Continue...
● #php composer.phar depends <package_name> <version> -t
● We can use --tree or -t flag to see a recursive tree of dependencies.
#php composer.phar depends psr/log -t
psr/log 1.0.0 Common interface for logging libraries
|- aboutyou/app-sdk 2.6.11 (requires psr/log 1.0.*)
| `- __root__ (requires aboutyou/app-sdk ^2.6)
|- monolog/monolog 1.17.2 (requires psr/log ~1.0)
| `- laravel/framework v5.2.16 (requires monolog/monolog ~1.11)
| `- __root__ (requires laravel/framework ^5.2)
`- symfony/symfony v3.0.2 (requires psr/log ~1.0)
`- __root__ (requires symfony/symfony ^3.0)