When working on large projects with one codebase you have to set up everything only once. But those of you who do a lot of small projects, how do you cope with it?
Do you set up everything from scratch every time? Let’s say you change your PHPStan settings, how do you promote this change to all of your projects?
I currently do the following:
Create a project with composer (symfony/website-skeleton)
Require my own package with utility classes I use
Open an old project and copy configuration for PHPStan, Easy coding standard, monolog, sentry, …
This has drawbacks. I have to do it manually every time and if I change any of the configurations it’s not updated automatically in all projects (e.g. on running composer update).
How are you working around this issue?
I think forcing auto-updates like this will lead to broken code…
Although it may not be the best or prettiest solution, I have one main composer package which I require in all my projects. This package holds all my default files like editorconfig, phpstan, phpcs etc. In all my projects I include a post-autoload-dump command which checks these files and updates the files if needed. That way if I change f.e. example the editorconfig file in my main package it gets updated automatically in a project if I run composer update.
Extra: I have added an – – ignore argument to exclude files from updating, if a specific project needs f.e. a different phpstan configuration.
Extra 2: I call this package my “core” package, which I can override with additional framework-specific “core” packages like “core-symfony” or “core-laravel” which provide different or additional configuration files.
I keep my small projects separate and isolated so that I am never in a position where I break something and I dont have the time to update and completely test it.
Work some dev ops magic. Write a script or three in Python, bash, or even PHP to automate this stuff.
When you want to change configuration or update something across the board, just run a script to batch process it against all projects.
I see several approaches to this.
mono repo with more projects – would you have projects that are similar (one big project composed of several microservices) you can put them in same repository and share the configurations for phpstan and vendor.
if you do lots of different projects then create your own Symfony skeleton that’s is preconfigured and fork new projects out of it. Not every project its the same and sometimes it doesn’t make much sense to share configurations like that
If all the confiruations are the same across all sites, just use github to store them in a private repo.
I just have a micro microservice library that just has one endpoint. I use one-to-many architecture. It’s relativity simple.
We have a library (companyname/dev) that pulls in https://github.com/phpro/grumphp and holds configuration files for a bunch of tools. The library is set up as a composer plugin and on install/update, it will automatically publish new *.dist versions (like psalm.xml.dist) of said config files. For project-specific configuration, copy the *.dist and make changes to the copy (like psalm.xml). If you don’t need some of the tooling, you can list the config files you don’t want in the composer.json’s extra.companyname-dev.skip. Grump will set up pre-commit hooks, so all the tooling will run automatically.
Basically, you just composer require --dev companyname/dev and you’re good to go. Took me maybe half a day to set up the package and it’s worked flawlessly so far.
Since we use Laravel a lot, we’ve also made an internal fork of https://github.com/laravel/laravel with a couple of changes (like setting up our private packagist, requiring the dev package, …) and create projects based on that using composer create-project.
You could set up a blank project with all the stuff you mention (symfony skeleton, your libs, etc). Properly set up and configured ready to start cracking on. Then use composer create project against it.
You could use git repository for configuration, tag changes and load to projects as git sub-module.
> how do you cope with it?
Take the learning from parenting project(s) and apply them to more projects. Review. Improve. Rinse and repeat.
Another method is to re-consider for each non-parenting project what the need was to actually add a new project and what an alternative approach could be.
You’ll learn about dependency management, project (mis-) configuration and tooling.
Provide feedback and patches to tooling projects that are part of your stack, in general to all things part of your stack. Each project is different, but the tooling and stack is shared. E.g. composer in PHP projects. Seems a no-brainer to use composer? Consider a moment how it came to be. All these things are done by people like you.
In case when you use a skeleton for your projects, improve it if that is practically feasible.
Automate all the things, commit your scripts.
> How are you working around this issue?
If you’re explicitly asking for working around, reducing the number of projects is often the first quickest win as then there is less to work around. Otherwise it’s merely just work IMHO. There is no one-size-fits-it-all and beware of marketing. Best thing you can normally do is to share your issues. This is normally both good for learning more and as well to not re-invent the wheel. E.g. I normally look if the problem I run into is one extraordinary specific to my current project (likely not, most problems have been solved already, look for these solutions) – yes subjectively all my problems are extraordinary specifically in need of a fix to me right now. But yeah, better not.
What you can also consider is to do project farming, that is have one code-base that applies processes onto a farm of projects. E.g. automate copying over phpstan configuration, it may not be very interesting (as it’s more interesting to build up on them in a certain project), but many of these tools have a baseline feature, so that you can apply the same configuration on all projects and then have it ongoing as existing errors don’t count, only new ones. This normally also integrates well with the IDE you use next to existing projects.
Have a project that keeps track of these reaching-over-project boundaries scripts and put it under distributed version control. Many people do this with their dotfiles. There is a full botanic garden out there to explore when you search for that topic.
And in the IDE, most of them offer per project but also more global configuration. E.g. it should be that with an IDE it detects this is a PHP project and then offers all the support that applies to the project itself without further ado. E.g. showing the phpstan errors annotated in the code opened in the editor. E.g. I report all issues I have to the vendor of my IDE and ask for support. Some are getting patched suit, some not, and for some it’s good that they are not getting patched at all.
In the old days, it was more about writing the code right directly as the tooling came later. Nowadays it’s more that tooling runs alongside while writing which can be distracting a bit. But it’s also today that much of the tooling can apply fixes directly, this is normally use-full when preparing a commit close to committing it.
Which again is tooling configuration within projects managed by (distributed) version control. If it’s shared, why not fetch from a remote that is a different project on your box? Cherry-pick for the win, there is nothing wrong in learning distributed version control when in the end it’s about sharing.
Just my 2 cents.
https://i.redd.it/jteumsg7y4861.jpg
Copy-paste my docker compose for Laravel. I do optimize it for production build once by stripping some unwanted elements.
The easiest way IMHO.
Dev env does not have to be perfect, it have to has unit tests and just run. Production build is still similar to dev, but with stuff like enabled opcache and removed pcov / xdebug from php build