Freek.dev

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 version 2 will be mostly compatible with your existing workflows, while bringing some more great new features.

Read more [php.watch]

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]

Bram Van Damme explains how you can get autocompletion for most composer commands.

Read more [www.bram.us]

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]

#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]

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]

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

Read more

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/

Read more

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.

Read more

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/

Read more

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/

Read more

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.

https://seld.be/notes/typo-squatting-and-packagist

Read more

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

Read more

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.

What 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:

Read more

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.

...

Recent changes have made it much easier to develop Composer plugins.

Read more

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.

In 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.

Read more

Jack McDade, who designed the laravel.com and laracasts.com sites, shares some tips on how to make composer and npm much faster.

Whenever I run `composer install` or `npm install` I feel like an old man yelling at young punks to get off my lawn. Especially ever since `npm3`. I’ll save you the bitter diatribe and just get to the solution. But first, the problem.

Creating, distributing, maintaining, and consuming third-party dependencies was supposed to make us more productive and our lives easier. Instead, I feel like I spend more time waiting than coding.

So I dug and dug until I found solutions, as one does, and now I’m sharing them with you.

Read more