Why fork Pattern Lab?
Pattern Lab + D8 Is Maturing The Pattern Lab community is growing like crazy (yay) - we’ve got a growing little team of genuinely passionate, creative folks putting their blood sweat and tears into making Pattern and Drupal really freakin work well together, which, requires Pattern Lab itself to be actively worked on as well.
So The Community Is Finding Holes + Proposing Fixes As a result, a lot of us have run into some snags / kinks / issues / insights along of the way when figuring this whole Component Driven Development + Pattern Lab for Twig + Drupal 8 thing out, especially in the context of real world projects. That’s generated a ton of creative workarounds, plugins, code forks, PRs, issues, Gulp tasks etc etc etc.
Pattern Lab Improvements + PR’s in Limbo = :( Unfortunately, due to understandably constrained resources / limited responses by project maintainers, a lot of the really awesome contributed community work being done in bullet 2 is getting stuck in an almost indefinite limbo. And if you’ve got 2+ PRs you submitted 8 months ago that still hasn’t gotten any feedback or hasn’t yet been reviewed, are you REALLY going to feel confident that any future PR’s aren’t going to meet a similar fate?
Forks Out Of Love So that brings us back to the whole forking bit. This is all being done purely out of necessity / love.
I think I can speak for everyone in saying that we all really really want Pattern Lab to work and to continue to be the poster child of atomic design / pattern driven development. That’s why this is “Drupal Pattern Lab” vs “Drupal + Fractal” or “Drupal Fabricator”. Forking PL is simply a quick way to get #s 1, 2, and 3 addressed in a timely manner (fast-tracking all this) while still keeping the door open to getting all this hard work folded back in.