Recently, I've been revisiting some of my old side projects. I'm in the process of consolidating all those projects onto a single server. This would help with cost of managing all of them, and also merge all the Apache2, nginx, Traefik, uwsgi, actix-web, and whatnot web servers configurations I tried over the last 10 years. This project is quite satisfying and feels like a form of introspection on the different things and technologies I tried in my free time over the years.

I thank my past self for simplifying projects on-boarding: most projects do have a Makefile and a deploy.sh file to manage build, run, and deployment. It makes wrapping one's head around a forgotten project straightforward. Most of those projects only had a single developer working on them, though, it remains valuable to have a consistent entrypoint to spin up a polyglot tech stack.

There is one hurdle I encountered though, independently of what package manager I would use, nearly none of the projects I worked on builds or runs on the first try. There would always be a dependency that is no longer available or incompatible with the toolchain I have on my computer in 2023. And then, upgrading that dependency becomes a game of whack-a-mole between upgrading to a recent-enough version, but not needing to upgrade peer-dependencies that are now no longer compatible with those breaking changes.

In that context, semver is of no help. Anything can be a breaking change.

Vagrant, Cargo, requirement.txt, Opam, Dockerfile, npm, yarn, all would fail in one way or another.

A couple of projects did build and run on the first try, and the satisfaction of seeing the programs run without a hassle was kind of similar to doing a strike at bowling on the first try!

There is one exception though, and it would be for Go projects. If anything Go got right for long-term maintainability, it would be dependency management. Contrary to other dependency managers, go-pkg downloads the source code locally and stores it on disk. Come back 1, 5 or 10 years later a go project will build (assuming that the compiler remains the same).

There is a tension though, go-pkg is not the only package manager to download the dependencies locally (all of them do it one way or another). However, given the size of those dependencies in other languages (e.g. node_modules) go is one of the only languages where it is considered good practice to checkout the vendors to the VCS.

This might be utopian, but the take-out is that for small side projects to remain maintainable over the years, strive to have all the code checked-out in the VCS, and keep them small.