Horde was never on the hip & trendy side of town. When everybody called monorepos dead, we did a monorepo. Shortly before the great monorepo revival, we did a git split into distinct libraries. This required some tooling. Michael Rubinsky’s git-tools was great for its time. It handled what we couldn’t have handled manually. Now monorepos are all the rage but we aren’t going back. In this article I am going to outline the playground rules for the different types of packages and how we try to enforce them.

horde-library

These are packages which need special handling. They depend on the horde/horde-installer-plugin package. This is for packages which expose javascript to the web dir or have a migration/ directory with extra classes for database schema handling. These packages MAY depend on frameworky packages which pull in more dependencies of the same type. Their tests CAN depend on horde/test but they probably shouldn’t.

library

These packages can be installed without the horde/horde-installer-plugin using vanilla composer behaviour. The SHOULD NOT depend on a horde-library and SHOULD depend only on packages they strictly need. Their unit tests SHOULD NOT depend on the horde/test package.

horde-theme

These are theme plugins for horde. They should only contain very limited php as a form of meta data and follow a strict format. They should be leaf packages, no dependencies except on horde-plugin.

But what can I say?

Enforcing rules is the tricky part. Currently we are experimenting with custom php-cs-fixer and phpstan rules to detect architecture violations. One such violation was direct usage of sabberworm classes in the code base outside of the horde/css_parser library. It was detected, it will be fixed and then we can safely upgrade sabberworm dependencies without risk of breaking anything. Implementing rules for each package type will be a challenge to come.