ProductivityProgrammingTechnologyWeb Development

Recent years have seen the proliferation of high-quality package management tools for a wide range of web development languages. Ruby’s gems were always a key selling point of that platform, allowing for a sort legendary developer productivity which is now, thankfully, widely available regardless of platform.

But dependency management is an art unto itself, one that many give little thought to until something breaks catastrophically, leaving developers scrambling to patch some obscure dependent module they didn’t even know they had, as the left-pad debacle did for Node.js developers earlier this year.

If, as developers discovered that day, your project is only as strong as your weakest dependency, it’s prudent to have a handle on what you’re pulling in, from whom, and how you’re doing it.

Big names like Facebook were caught off-guard as everyone else, and the desire to be in control of their dependencies has doubtlessly led to the creation of yarn, a new JavaScript package manager, which we, too, are very excited about.

Operating alongside npm, meant as a drop-in replacement, Facebook touts the following benefits:

  1. Speed
  2. Reliability
  3. Security

The latter two benefits are tied to a .lock file, something that PHP users of Composer are likely familiar with, but which npm lacks:

The magic clue behind it? Whenever you run yarn install, the yarn.lockfile has precedence over the package.json.

If the yarn.lock file exists, the (exact) versions defined in it will be used.

If no yarn.lock exists, the (loosely defined) versions defined inpackage.json will be used, and a yarn.lock is generated.

Dependency Management for PHP

Package management on the PHP side seems comparatively safe and manageable. PHP has an extensive standard library, and we’re unlikely to pull in 100 packages to boot a simple application. It’s much easier to survey the landscape of an application’s dependencies and get a feel for what’s there and why it’s there.

Features that yarn aims to bring to the table for JavaScript developers, such as that lock file, have always been part of our workflow. So, perhaps you haven’t thought about it too deeply.

In fact, you might have questions which are worth reviewing.

Why the composer.lock file matters

How precisely does it relate to composer.json? Should I commit it to version control? How do I manage conflicts?

Managing PHP Dependencies Properly

What should I pull in as a dependency, and what as a dev dependency? Should I need to modify a dependency, what’s the correct way to go about it? How do I optimize my package usage for production?

Above all, be mindful of what you pull in, what that which you pull in pulls in, and the faculties your toolchain offers to allow you to manage these, lest today’s convenience lands you in an uncomfortable situation down the line.


A place for Edmonton-area PHP developers to meet and collaborate. Administered by

EducationProductivityTechnologyWeb Development

A client who wants a web app, and their internal IT told them they should use Ruby on Rails. During our initial exploratory period, we discovered that there was no existing quality libraries or Ruby Gems that covered their needs in Ruby. Now, Ruby is not a terrible language by far, but there simply wasn’t the tools to build this at this time.

Now, if we were a Ruby-only house, we would just charge them more to develop everything from scratch, and charge them to maintain it for the foreseeable future. Great short-term business model for us, but not so perfect for them; In other words, precisely why we are not that way; we want to save our customers money because when they succeed, we succeed.

How do we help you reach your goals? Well, we are your dedicated CTO, we are not just a Ruby-only house. In our exploratory meetings, we had our PHP and Node.js experts on hand. Both of whom quickly pointed out that there were specialty libraries that were established and clean in their languages, and that we could implement this entire system in likely half the time using those software libraries.

So, we finished off the work outline document with a quote for Ruby which ended up being almost double the quote for developing the same app in Node.js or PHP. We explained the reasons we felt that we did not need to stick with Ruby; They wanted to use a cloud service that supported Ruby, and there were similar, equally-priced ones that supported other languages. Moreover, we explained why we felt that using PHP or Node.js would save money in the long run.

If we were a one-trick pony house, but exquisite at that one trick, you would not get the best options.

ProgrammingWeb Development

An Earth-shaking release like PHP 7.0 is tough to follow-up, and at first glance, the upcoming PHP 7.1 release appears, shall we say, not as exciting as the last. But don’t let that damper your enthusiasm, for the PHP 7 line is indicative of a language reaching a state of maturity and stability, and what we have with 7.1 is a cautious incremental release that moves things forward at a pace befitting this.

Indeed, #internals is full of exciting RFCs mapping future courses that we’d love to tinker with today, but are not decidedly not ready for prime-time. As much as we like new toys, we spend enough time staring down large PHP codebases that we’re excited by many of the incremental improvements found in 7.1.

Let’s run through those areas of improvement that have caught our eye.

Return Types

The addition of Return Types in 7.0 has gone a long way toward solidifying our APIs, moving vital interface parameters out of documentation and into the code, where the parser can enforce what was previously a suggestion. 7.1 brings two subtle but useful refinements of this system.

Void Return Types allow you to specify a function that is expected to return literally nothing, whereas before you would omit the return type and specify void in the documentation block accompanying the function.

Nullable Types allow for returns that are either a specified type or a null, much as you might specify

ObjectType $variable = null

upon input, allowing either that type or nothing at all. This is one that we’re looking forward to in particular, allowing for more flexibility in the construction of cohesive interfaces.

Array Unpacking

Having worked extensively with ES6 and having become very used to its destructuring syntax, this is an area of welcome improvement.

First is a more concise notation, optionally replacing the use of the list keyword, bringing things more in line with the square-bracket array syntax we’ve enjoyed since 5.4.

Second, the allowance of keys within the list construct allow properties to be extracted by name, much as we’ve come to expect on the JavaScript side.

Iterable Pseudo-Type

PHP has long had the Traversable interface, allowing iterable objects to be treated relatively interchangeably and foreachd without regard to specifics, much as you’d treat an array. Except array itself is not an object, and could not be interchanged with a Traversable. You could specify an iterable object or an array, but not both at once.

7.1 resolves this with Iterable, nicely encompassing array primitives and iterable objects under a single umbrella. It’s a small change that brings considerable flexibility to your API.

Closures from Callables

Over the past couple years, our framework has come to be increasingly driven by callbacks, while avoiding some of the common pitfalls through sensible class-based organization (patterns our ES6 and PHP7 codebases have increasingly come to share.)

However, JavaScript objects are wide open and lack a concept of private or protected members. Previously, class-bound callables we wished to pass around had to be marked public in our PHP codebase, even when it would be appropriate to limit and allow the parent class to dispense access.

This could be accomplished with hacky workarounds that we’d rather not use in production, but now we have a language construct to do so in a safe way.

… and more!

Head over to for an exhaustive list, and tell us what you’re looking forward to in the comments.

Finally, remember that the PHP development process is a remarkably open and democratic one, and that you too can get involved and help shape the language’s future.

ProductivityProgrammingWeb Development

In many ways, the transition to PHP 7, from the 5.x line we had used for many years before, was a clean break, an opportunity to clean house and sweep aside development practices and software dependencies that had outlived their usefulness.


Operating on a codebase which had grown out of the days and practices of CodeIgniter and their ilk, which had proved useful for years but was unquestionably showing its age, we jumped at the opportunity to build the framework we would like to use in 2016, rather than the one we had inherited from 2009.

Here was an excuse to revamp our development practices, throw out bits that made sense in 2008 but were a source of a headache today, and incorporate improvements that have taken hold in the ecosystem in the meantime.

Most notable improvements are the standardization efforts that have occurred under the umbrella of PHP-FIG, and the package management ecosystem(courtesy of Composer) that these standards have enabled and allowed to thrive.

A packaging system is something that, given a lack of, you will inevitably try to invent yourself — poorly, incompatibly, and inevitably counter-productively. Such was the state of the PHP framework ecosystem before standardization, and the reorientation of our own framework from an inward-facing framework to an outward-looking one. A framework which naturally integrates with third-party packages and is itself incorporated into third-party packages in a similar fashion.

In this series, we will explore the changes that have occurred in our own development practice, the ways in which these are reflective of the ecosystem as a whole, and why these make for such an exciting time to be writing PHP on the backend.

Stay tuned.