Composer: Using your own local package
Because sometimes your spaghetti code should be kept for yourself only.
When developing multiple applications, repeating the same code in multiple projects is something that I personally consider against DRY. Copy-pasting the files, or using symlinks, sounds like a good idea, however, there is a way to centralize that code without publishing to the Internet.
For example, in my Podcast application shares code with another application. In particular, code to log actions made by a User into the database, so I can now who is the main culprit when something that shouldn’t have happened… happens. Also, I don’t want people to peek into my code, I did it drunk and it looks like a screaming Roomba.
A nice way to reuse the same codebase is to locate the code in some place, and tell your projects to kindly use the files located there. Of course, no need to hack into the filesystem, use symlinks, or even publish your code on the Internet.
This can be done magically by Composer, using a local repository, in two steps.
Step 1 — Setting up the Codebase
If you feel like a pro, use composer init to create the manifest that describes your package. Go to your codebase root folder, hit the terminal, and follow the instructions.
For sake of easiness, I’m gonna point you to the Laravel Package Boilerplate, which sets almost everything ready to start making our Composer package. Just select “PHP”, put some details, and then download into someplace safe in your computer to use it later, like /Users/Local/SpaghettiCode.
You will get a lot of files inside a ZIP archive, but the one we are interested is the composer.json. You can delete everything except for this file if you don’t plan to upload your package to the Internet in the future.
This new composer.json instructs Composer to treat the codebase as a Composer package. We only need to correct and simplify some things, like what PHP version it requires.
If you need additional packages, no problem, you can also point them here. Just be sure to not install them inside the package, like when you use
composer install. The project that would need this package will automatically do so.
We can put our files to match the namespace by PSR-4 standards, by putting them inside the src folder.
Step 2 — Adding the Local Repository
Now that we have our files ready, we need to tell our projects to use this package. For that, we need to instruct the composer.json of our project to check a local path for packages.
Once done, you’re ready to use the package in your projects as any other package you require:
Benefits
Yep, that’s all. It’s very easy and clean to implement, but that’s not the only benefit of using this way to handle commonly used code in your projects.
- Reuse the same codebase, without having to care about updating modifications across multiple projects.
- Test the code once, instead of testing it in every project.
- You don’t need to deal with Packagist or any Internet-based-VCS like Github, Gitlab or Bitbucket.
- It works with VCS if you are using it in your package, like
git. - Since it considered a package, it won’t meddle with your project files in any way.
No need to manually symlink folders, copy-pasting files manually, or dealing with publishing the package to Packagist or Github so everyone can laugh at your warm turd of a hairball code.
