Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Jonathan Reinink I live in Canada. I have been writing PHP for 18 years. I spent a decade at marketing agency. I am now a contract developer.

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

What is a package?

Slide 5

Slide 5 text

Packages are important because they provide code you don’t have to write.

Slide 6

Slide 6 text

Today there are 139,000 PHP package available on Packagist.

Slide 7

Slide 7 text

packagist.org/statistics

Slide 8

Slide 8 text

Packages are a BIG part of what makes a language successful.

Slide 9

Slide 9 text

Have you ever contributed an open-source PHP package?

Slide 10

Slide 10 text

Contributing to open-source helps both you as developer and the greater PHP ecosystem.

Slide 11

Slide 11 text

If your business relies heavily on certain packages, those are great places to get involved.

Slide 12

Slide 12 text

Creating packages can be a little intimidating.

Slide 13

Slide 13 text

Introducing The PHP Package Checklist phppackagechecklist.com

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Recommendations for open-source packages, but applicable to any PHP library.

Slide 17

Slide 17 text

Pick a name wisely

Slide 18

Slide 18 text

Have a unique identifier in your package name.

Slide 19

Slide 19 text

Twig Guzzle Monolog Flysystem Swift Mailer Eloquent Blade Aura

Slide 20

Slide 20 text

Ensure the name isn't already used by another project.

Slide 21

Slide 21 text

Maintain consistency between this name and your PHP namespace.

Slide 22

Slide 22 text

Avoid using last names or personal handles in your PHP namespaces.

Slide 23

Slide 23 text

// Good: namespace Glide; namespace League\Glide; // Avoid: namespace Reinink\Glide; namespace Images; namespace ImageManipulations; namespace PHPGlide; namespace YoloImages;

Slide 24

Slide 24 text

Host source openly

Slide 25

Slide 25 text

Hosting your code openly encourages: • Contributions • Downloads • Code Reviews • Bug Reports

Slide 26

Slide 26 text

Recommendation: GitHub

Slide 27

Slide 27 text

Even if you prefer Bitbucket, SourceForge, or Google Code, your end users most likely won’t.

Slide 28

Slide 28 text

Autoloader friendly

Slide 29

Slide 29 text

Use a PSR-4 compatible autoloader namespace.

Slide 30

Slide 30 text

Distribute via Composer

Slide 31

Slide 31 text

$ composer require league/glide

Slide 32

Slide 32 text

{ "name": "league/glide", "require": { "intervention/image": "^2.1", "league/flysystem": "^1.0", "php": "^5.4 | ^7.0", "psr/http-message": "^1.0" }, "autoload": { "psr-4": { "League\\Glide\\": "src/" } } }

Slide 33

Slide 33 text

List your library on Packagist, the main Composer repository.

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Committing your composer.lock file has no impact on your end users.

Slide 36

Slide 36 text

Place code in the /src folder.

Slide 37

Slide 37 text

Framework agnostic

Slide 38

Slide 38 text

Don't limit your library to one framework.

Slide 39

Slide 39 text

Offer framework specific support for your package using service providers.

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Follow a coding style

Slide 42

Slide 42 text

Highly recommended that you adhere to the PSR-2 coding style guide.

Slide 43

Slide 43 text

A familiar coding style makes open-source code easier to contribute to.

Slide 44

Slide 44 text

Do this quickly with an automated code fixer like PHP Coding Standards Fixer. cs.sensiolabs.org

Slide 45

Slide 45 text

You can also use services like Nitpick or StyleCI to help you with this.

Slide 46

Slide 46 text

Write unit tests

Slide 47

Slide 47 text

Aim to cover the majority of your code.

Slide 48

Slide 48 text

PHPUnit is the de facto testing framework in PHP.

Slide 49

Slide 49 text

Alternatives: phpspec, Behat, atoum, Codeception.

Slide 50

Slide 50 text

DocBlock your code

Slide 51

Slide 51 text

/** * Set source file system. * @param Filesystem $source Source file system. */ public function setSource(Filesystem $source) { $this->source = $source; }

Slide 52

Slide 52 text

DocBlock serve as inline documentation.

Slide 53

Slide 53 text

They can also improve code completion in IDEs, like PhpStorm.

Slide 54

Slide 54 text

Can be automatically converted into API documentation.
 (see phpDocumentor)

Slide 55

Slide 55 text

Use semantic versioning

Slide 56

Slide 56 text

Follow the pattern: MAJOR.MINOR.PATCH BREAKING.NEW-FEATURES.BUG-FIXES

Slide 57

Slide 57 text

Semantic versioning allows developers to upgrade libraries safely.

Slide 58

Slide 58 text

semver.org

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Keep a changelog

Slide 61

Slide 61 text

Show notable changes that have been made between releases.

Slide 62

Slide 62 text

Consider following the Keep a CHANGELOG format. (see keepachangelog.com)

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

{% for release in site.github.releases %} ## [{{ release.name }}]({{ release.html_url }}) - {{ release.published_at | date: "%Y-%m-%d" }} {{ release.body | markdownify }} {% endfor %}

Slide 65

Slide 65 text

Use continuous integration

Slide 66

Slide 66 text

Use a service to automatically check coding standards and run tests.

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

Write extensive documentation

Slide 70

Slide 70 text

“Tests are hard so we practice to get better. Docs are hard… so we don’t write any and complain.” — Steve Klabnik, Senior Technical Writer (maintainer of the official Rust documentation)

Slide 71

Slide 71 text

Don’t release an open source package unless your committed to writing good documentation.

Slide 72

Slide 72 text

Consider hosting documentation on GitHub Pages.

Slide 73

Slide 73 text

The formula to awesome docs:
 Tomorrow at 11am

Slide 74

Slide 74 text

Include a license

Slide 75

Slide 75 text

See choosealicense.com. Most PHP projects use the MIT License.

Slide 76

Slide 76 text

The MIT License Copyright (c) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Slide 77

Slide 77 text

At a minimum, include a LICENSE file with your library.

Slide 78

Slide 78 text

Welcome contributions

Slide 79

Slide 79 text

Have a CONTRIBUTING file, welcoming contributions to the project.

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Thanks! Follow me on Twitter at @reinink. Please rate this talk at joind.in/talk/74e5f.