During the initial stages of developing a Composer package, you probably don’t want to go to the trouble of setting up an empty Packagist package. You probably also shouldn’t be developing in the vendor directory.
I haven’t done much research on the best workflow for this solution - but the method described in this article, which utilises a Composer path repository - seems to work pretty well. I heard Taylor Otwell (creator of Laravel) talk at Laracon Online last week and he uses this approach.
In your project root directory, create a ‘packages’ directory. This in turn should contain a ‘vendor-name’ directory which shouild contain a ‘package-name’ directory:
I think it’s best to name directories according to Packagist naming conventions.
Composer Init in the New Project
Move into your project and run
Composer will prompt you to set important metadata like the package name. This will be needed later when Composer (at the parent project level) attempts to auto-load your new project files.
Set Up Path Repository
In the main project
composer.json, you need to create a path reference for your package within the “repositories” section. The following fragment from the parent project
composer.json defines two Composer path repositories,
wp-metadata-accessor. In this particular case, the parent project is cloned from the Sage WordPress starter theme - which comes already set-up for Composer.
Require Local Packages in composer.json
Once the repositories have been set up with the correct path, you can add them to the project dependencies, as shown in this extract:
Important: if you have a local repo without releases (maybe you haven’t even run
git init yet), you need to specify
"dev-master" for the required local packages.
"*" won’t work.
Within the new project
composer.json, set up autoloading paths:
This sets the new project’s namespace. Once you’ve run
composer update, your project classes will be autoloaded.
Composer Update Connects (Symlinks) Things Up
In the parent project root directory. Composer will then create a new vendor-name directory with the project
vendor directory. The package files will be symlinked here. For example:
This allows you to work on your new package from within your
packages directory, but still have your project included within Composer (with dependencies, autoloading, etc).
Composer Update Problems
I recently hit a snag when setting up a package for development in a Laravel project:
This happens because if the path-repository project that you’re requiring is not a VCS repository, you need to explicitly define the version in the package
If the package is a local VCS repository, the version may be inferred by the branch or tag that is currently checked out. Otherwise, the version should be explicitly defined in the package’s composer.json file. If the version cannot be resolved by these means, it is assumed to be dev-master.
— Composer documentation on path repositories.
In my case, I solved the issue simply by running
git init in the package directory.
comments powered by Disqus