How to Build and Autoload Your Own PHP Package Locally
Matt Stauffer shows a good workflow for this.
Read more [mattstauffer.com]
How we created over 200 PHP and Laravel packages original
I work at and co-own a company named Spatie, which specializes in creating large Laravel applications for our clients. Our team is rather small: we consist of only 10 people. At first glance we are a software development company like there are so many others. But there’s one thing that sets our company apart: we have an open source first policy. We try to create and contribute to open source as much as possible.
Currently we have around 200 open source repositories on GitHub. Our packages have been downloaded nearly 75 million times. They are being downloaded 4,5 million times each month. Probably we will hit 100 million downloads by the end of this year.
We've also just released our premium video course, titled Laravel Package Training. In this course, we use our experience to teach you how to build reliable and maintainable packages.
This all did not happen overnight. Read on to learn the story behind our open source efforts.
Join 9,500+ smart developers
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
"Always fresh, useful tips and articles. Carefully selected community content. My favorite newsletter, which I look forward to every time."
Composer 2: Platform Check
Composer v2 has a new feature that your server environment is checked at the run-time before the autoloader is even initialized. This is everything you should know about it
Read more [php.watch]
Composer 2: What's new and changed
Composer version 2 will be mostly compatible with your existing workflows, while bringing some more great new features.
Read more [php.watch]
Find outdated PHP dependencies
Not sure if your dependencies are up-to-date? Run `composer outdated` and find out. ⚡️ pic.twitter.com/6ZShopPapn
— NUNO MADURO ➕ (@enunomaduro) December 3, 2019
Read more [twitter.com]
Bash/Shell Autocompletion for Composer
Bram Van Damme explains how you can get autocompletion for most composer commands.
Read more [www.bram.us]
Fake PHP version in composer
Anna Filina explains the handy platform option you can use in composer.json. It's a good idea to just use this in all of your projects.
Say you run the latest PHP version on your machine, but the server runs PHP 5.5. This means that when you decide to add a Composer package, it might propose a version that may not be installable on the server. The solution is surprisingly easy. You can instruct Composer to see the PHP version of your choosing.
Read more [afilina.com]
Find out which composer dependencies have released new major versions
#Laravel tip of the day: if you want to find out which of your composer.json packages have released newer versions, just run "composer outdated". You will get a full list with all information. pic.twitter.com/2FOw39TBr4
— Laravel Daily (@DailyLaravel) March 6, 2019
Read more [twitter.com]
Verifying Laravel Version Compatibility
TJ Miller shares a cool Travis config to tests against all versions of Laravel.
As Laravel 5.7 is now out, I needed to add support to both the package’s composer configuration and verification in CI. Previously, I only needed to verify against 5.5 and 5.6 I thought that having --prefer-lowest in the matrix would add the coverage I needed. Now that I am supporting three versions I felt that I needed a more specific way of verifying compatibility with different versions of Laravel.
Read more [blog.tjmiller.me]
Run a package from a local directory
Barry Van Veen shares how you can install a package from a local path into your project. This is extremely handy when developing a package because you can immediately toy with it in a full application.
This article explains how you can require a package from a local path into your project with Composer. This way you can run a local copy of a repository and test any changes you make. Because the local repo will be symlinked changes are shared in real-time, there is no need for intermediate committing and updating.
https://barryvanveen.nl/blog/44-package-development-run-a-package-from-a-local-directory
17 Tips for Using Composer Efficiently
Martin Hujer shares some pretty good tips for working with Composer.
Although most PHP developers know how to use Composer, not all of them are using it efficiently or in a best possible way. So I decided to summarize things which are important for my everyday workflow.
The philosophy of most of the tips is "Play it safe", which means that if there are more ways how to handle something, I would use the approach which is least error-prone.
https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/
Introducing Private Packagist
Jordi Boggiano and Nils Adermann, creators of Composer, have recently released a paid version of Packagist. The service aims to make managing private packages a breeze.
Private Packagist aims to remove all these hurdles for businesses to finally make working with Composer as convenient as it should be. Being a hosted service, setting up your own Composer package repository on Private Packagist is done with a few clicks. No matter if your private source code is hosted on GitHub, GitLab, Bitbucket, any of their on-premise solutions, or in any other Git, Mercurial, or Subversion repository, Private Packagist can immediately access your code after setting up your credentials to make it available for installation through Composer.
https://medium.com/packagist/introducing-private-packagist-492553d10660
If you're not afraid to get your hands dirty you could, instead of using Private Packagist, choose to use Satis. This tool is also written by Jordi & Nils. Laravelista has posted this great tutorial to get you started with the tool.
At Spatie we have set up a satis server to register packages that are intended to only be used in our own projects.
How to automate projects using composer scripts
On the Master Zend Framework blog Matthew Setter explains the scripts section of composer.json.
The scripts section of composer.json allows you to set up a range of commands which relate to your project, commands which call command-line executables and PHP callbacks.The commands can be named as you see fit, such as test, clean, deploy and so on. Or they can use the names of events which Composer fires during its execution process, such as post-root-package-install, pre-install-cmd, and post-package-update.
In today’s tutorial, I’m going to take you through examples which highlight both approaches
http://www.masterzendframework.com/series/tooling/composer/automation-scripts/
Our packages have been downloaded one million times original
I'm very happy to announce that, as of today, our Laravel and PHP packages have been downloaded a million times. We now have more than 80 packages registered on Packagist. All combined they are downloaded around 150 000 times a month, and that number seems to be growing. Our GitHub organisation has…
Testing your composer dependencies with prefer-lowest
An older but still relevant post by Evert Pot on why and how you should also test your packages with the lowest versions of it's dependencies.
In some projects, there may be packages lying around that are not the latest version. This could be because it introduced some BC break, or introduced a bug.If other packages also use the package that’s being held back, they may get an older version as a dependency.
So for package maintainers, they will want to find out if their package correctly works with the oldest package they claim to support.
https://evertpot.com/testing-composer-prefer-lowest/
EDIT: Here's another old, but also still relevant, blogpost on the subject by Cees-Jan Kiewiet:
https://blog.wyrihaximus.net/2015/06/test-lowest-current-and-highest-possible-on-travis/
Typo Squatting and Packagist
Jordi Boggiano investigated if there are pundits actively abusing typos in package names.
Earlier this month an article was published summarizing Nikolai Philipp Tschacher's thesis about typosquatting. In short typosquatting is a way to attack users of a package manager by registering a package with a name similar to a popular package, hoping that someone will accidentally typo the name and end up installing your version of it that contains malware.... I wanted to take a look at our repository data and see if I could spot any bad actors.
PHP 7 usage at 20% according to Packagist stats
Jordi Boggiano, the creator and maintainer of Composer and Packagist, released some fresh statistics on which PHP version composer users are running.
A few observations: 5.3 dropped to almost nothing which is great news! 5.4 is also down by almost 10% and is definitely on the way out. 5.5 is still big but less so, while 5.6 got a huge boost to become the main version. The big surprise is that we have 20% of PHP7 already! That is great news only six months after this major release came out.
20% sounds really great, but I suspect that this number is slightly optimistic. Many developers who are running PHP 7 in their dev environment use PHP 5.X in production.
Over on the package side only ±20% of all packages require PHP 5.5 or above and only 1% requires PHP 7. Jordi has this to say about that:
All in all, it seems like package requires are way behind actual version usage, so I would like to encourage everyone to be a bit more aggressive in bumping PHP requirements when tagging new major releases of their libs.
That's great advice. The bulk of the newly released Spatie packages require PHP 7. In my opinion you'd do our ecosystem a favour by picking PHP 7 as a minimum requirement when you are creating a new package.
Read Jordi's entire post on his blog for more details: https://seld.be/notes/php-versions-stats-2016-1-edition
Common files in PHP packages
Jordi Boggiano researched which files are common in PHP packages.
I queried GitHub's API for the file listing (only the root directory) of all PHP packages listed on packagist.org.https://seld.be/notes/common-files-in-php-packagesWhat this let me do is look at what files are commonly present (and not), which is quite interesting to get a picture of the whole ecosystem.
In total, this includes file listings from 78'992 packages (no GitHub API was harmed in the making of this blog post though). And here are a few interesting things that surfaced:
Drunk with the power of composer plugins
Christopher Pitt posted a tutorial on creating composer plugins on the Sitepoint blog.
Composer is the sharpest tool in the toolbox of the modern PHP developer. The days of manual dependency management are in the distant past, and in their place we have wonderful things like Semver.http://www.sitepoint.com/drunk-with-the-power-of-composer-plugins/...
Recent changes have made it much easier to develop Composer plugins.
Handling composers "lock file out of date" warning
Lorna Jane Mitchell explains on her blog which options you have when you see "lock file out of date" warning.
The `composer.lock` also includes a hash of the current `composer.json` when it updates, so you can always tell if you've added a requirement to the `composer.json` file and forgotten to install it.http://www.lornajane.net/posts/2016/handling-composer-lock-file-out-of-date-warningIn that case, you'll see an error message like:
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.You now have three options: upgrade everything, figure it out, or do nothing.
