Independent Packages and Subtree Splits

You’ll sometimes see a PHP package hosted in a Github repository with the heading or subtitle “[READ ONLY] Subtree Split”. This indicates that the package is actually copied from another codebase (usually a framework) and is not intended to be worked on separately from that other codebase.

As such, a “subtree split” is not necessarily a sign of an independent package. Using a subtree split to publish a package says to me that the authors’ concentration is on the framework-as-a-whole, not on the package in-and-of- itself.

For example, Symfony does subtree splits for its components, as does Laravel for its Illuminate components. Those packages from the frameworks are not developed independently; they only move forward as part of the whole framework.

In these cases, you often end up with composer.json in the framework origin directories, which is not something I generally expect. Further, the framework subdirectories may have their own src/tests/docs/etc. directories. They are there so that the subtree split can have them available at their own top level, but in the origin framework, it is again something I find unexpected.

I say: if you’re going to advertise independent packages, actually write them independently. Let them be their own thing. Aura has done it that way since its beginning, and Zend Framework converted to that approach in version 3. Then you can compose the truly independent packages into a framework, instead of subtree-splitting your framework into pseudo-independent packages that are still bound to the origin framework development and release process.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

2 thoughts on “Independent Packages and Subtree Splits

  1. That’s precise observation but I can say that:

    1. Being bound to release cycle has nothing to do with subtree split.
    2. Even w/o subtree split package may be dependent on framework core.
    3. Being dependent on the core isn’t necessary bad. In many cases these packages are leaner, more performant and easier to maintain than fully independent ones.

  2. Have you considered the counterargument – that a library may in fact benefit from being written in concert with components that it is intended to work with (though where working with said components is not mandatory)?

    I’ve not explored it, but consider a couple of hypothetical libraries; Acme\Validator, and Acme\Forms.

    Both are entirely happy working independently of each other but offer some benefit when used together.

    Surely then, working on them together aids in the goal of improving their usefulness to one and other?

    I’m sure lines should be drawn somewhere, and I’d prefer to see a lot more ‘packagising’ of libraries within a framework such as Laravel (especially where it is clear that they are only tangentially related – looking at you Illuminate\Support\Collection).. but do you see any advantage to developing like-packages together as a single body of work, and then splitting them out?

Leave a Reply

Your email address will not be published. Required fields are marked *