Why I built "Build Configs"
Build Configs is a tool I wrote and recently gave a lightning talk about at the PHP South West meetup in Bristol, UK.
It's a command-line tool that creates customised per-project configuration files from a set of reusable templates.
It's a Symfony project using components such as Console, Validator, and Twig for templating.
But why did I build it?
What was I doing before?
When starting a new project, I'd copy configuration files from an existing project and alter them as needed.
If a project uses a docroot directory instead of web, a different version of PHP, or Caddy instead of Nginx, I'd need to change the files manually for the new project, add any required features, or fix any bugs.
What was the issue with this?
It took time to set up new projects, and there would be drift between them.
I may have added a feature to one project, but it wouldn't exist in the one I was working on.
If I needed to move a feature from one project to another, I needed to do it manually.
How does Build Configs solve the issue?
Now, I have a canonical set of template files.
Instead of making ad-hoc changes to each project, I can add new features and fix bugs in the templates, and re-generate the configuration files for each project.
I don't need to worry about drift between projects because they're all in sync and generated automatically.
It's quicker to create and onboard projects using existing configurations instead of copying files and making manual changes.
If you want to see an example, watch this video where I set up a new Drupal 10 project from nothing to running website in less than a minute.
- Oliver
