The sabberworm/php-css-parser used to be bundled with the horde/css-parser library. Supposedly the one is a shield before the other, separating the code base from this particular beast. But over time it crept in and infested various places.

How to fight back

It’s time to teach the worm some manners and throw it out where it doesn’t belong. Bypassing a wrapper is an architecture violation and I won’t tolerate it. So what is the cure against the worm?

First I am going to MARK all such violations so I will find them again later on.
Then I classify the violations into patterns and use cases. I check: Is this already supported in the wrapper or must the wrapper be amended to properly support the use cases? Only then it’s time to expell the worm.

When to fight back

Once confidence grows that the wrapper is powerful enough, all the documented violations get changed to equivalent wrapper calls. The worm will retreat to his confined place in the wrapper where it can live happily ever after. I don’t hate the worm, I just want it to behave and keep to its places.

Why fight the worm?

Confining the worm usage to an adapter seems additional work at first but it brings a lot of joy. Updates become trivial as updating the wrapper and covering it with functional tests is enough to ensure the whole ecosystem will not break even from a major version upgrade. It comes at a cost – every new aspect consumed from the library needs to be modeled into the wrapper. Should there ever be a need to replace the worm with another CSS solution, the change is going to be very straight-forward.

Would you still love me if I was a worm?

It’s an interesting question but it’s a much easier question if the worm knows its place.