Discuss best PL to suggest

[EvanLovely]

@evanmwillhite Originally wrote:

It makes sense to promote a single Pattern Lab edition as the "blessed" Drupal edition, especially if the difference between it and the Twig edition is enough to justify a separate project.

Currently, it looks like the difference is in the twig-components? If so, could we separate off this just this piece into an add-on to the Twig edition? If not, do we want to add the Twig namespaces plugininto the edition?

[EvanLovely]

Then @aleksip commented:

The Drupal edition adds drupal-twig-components, plugin-data-transform and Drupal-specific StarterKit suggestions.

But as not everyone uses drupal-twig-components or plugin-data-transform and the current StarterKit install method isn't really developer-friendly (in my opinion at least), I'd vote for using the plain Twig edition as the recommended edition and providing good documentation about adding Drupal-related plugins, installing Drupal-related StarterKits etc.

[EvanLovely]

I think we should fork the Twig Edition and all it's dependencies (patternlab-php-core, patternengine-php-twig, and styleguidekit-twig-default), then work on getting the stagnant PRs from each of those repos evaluated and merged in, then release a new Twig Edition version. Afterwards we'll open up one big PR for each of our fork's master branches back to the upstream version if @dmolson decides to start maintaining them again.

Then, instead of working on a Drupal Edition, we have documentation on how to integrate the Twig Edition into Drupal and the different plugins that are useful for when working in Drupal.

OR:

If we want to keep the Drupal Edition I'm OK with supporting and maintaining two Editions (Twig & Drupal) as the Editions are pretty light wrappers around the majority of what's going on in the dependencies. If we get the PRs and issues fixed for one, it's nearly trivial to have the other Edition benefit.

What do you all think? @aleksip @evanmwillhite @sghoweri

[cybtachyon]

I prefer the idea of contributing mainly to the Twig Edition via a fork, to help abstract and make it a bit more useful.

One thing I dislike though

we have documentation on how to integrate the Twig Edition into Drupal and the different plugins that are useful for when working in Drupal.

Code > Documentation. I would maybe suggest a secondary goal for this project of creating a gulp/etc. tool that can be added to any Drupal theme to enable Pattern Lab support, while avoiding creating actual wrappers as a Drupal Edition like there are Angular, React etc.

To back it up, we are following these discussions at Red Hat closely and I at least can personally vouch for some of my own time invested & planned in making this happen. While I'm mostly focused on the Drupal admin side of the experience a-la Views + Components or UI Patterns modules, it follows that the admin portion can't exist without a full Pattern Lab implementation.

[evanmwillhite]

I too like the idea of our community helping to support the Twig Edition and then maintaining smaller plugins as needed. If I'm understanding correctly, https://github.com/drupal-pattern-lab/roadmap/issues/3 could possibly address @cybtachyon's request as well.

[EvanLovely]

I like supporting the Twig Edition as the primary suggested starting point the best as well. I actually think that non-Drupal Pattern Lab users would like that one the best out of all the Pattern Labs available as I think Twig is so much better of a templating language than Mustache.

I know @sghoweri agrees with this approach too but is traveling currently; so I think we have enough consensus for this approach – though I'd still love to hear thoughts from @aleksip Even if we go the Twig Edition route for a while then decide to get the Drupal Edition up to speed it'll be easy due to shared dependencies.

OK, so what I'm going to do is get our fork of the Twig Standard Edition using the forks of it's dependencies:

• https://github.com/drupal-pattern-lab/patternengine-php-twig
• https://github.com/drupal-pattern-lab/patternlab-php-core
• https://github.com/drupal-pattern-lab/styleguidekit-twig-default

And then able to composer create-project it. I've already got some work on this done and I know how we can side-step registering it on Packagist (PS No org account support for Packagist BTW). I'll also get Travis building PRs for us.

Next, we'll need to make an issue for someone to evaluate open upstream PRs and determine if they should be opened against our fork. Afterwards I think we should focus on a Minimum Viable Release - put out a bug fix or a minor enhancement: anything that shows we can ship and provides value to the community.

I have comments on the other ideas brought up that I'll come back to. This is awesome!

• [x] @EvanLovely creates fork of Twig Standard Edition
• [ ] Make issue for each dependency to review upstream PRs and suggest list to consider (not merge) for ours

[EvanLovely]

Alright, I've got our Twig Standard fork up with alterations and commands! Any testers? https://github.com/drupal-pattern-lab/edition-php-twig-standard/pull/1

[sghoweri]

TLDR: We should also fork styleguidekit-assets-default. Also, FYI, we're forking Pattern Lab out of love and hopefully can merge all this work back in.

Long version:

@EvanLovely completely agree. Focus is primarily on the Twig edition but there's going to be considerable overlap with the Drupal addition (I mean, it's litterally the same thing with just 2 added composer dependencies). Two small things to add though:

1. I'd recommend adding https://github.com/pattern-lab/styleguidekit-assets-default to your list of things being forked as that's a sub-dependency of our styleguidekit-twig-default dependency (and like the other parts that make up Pattern Lab, needs quite a bit of love). That leads me to...

2. Perhaps we should spell out as to why the forking portion of this new initiative is even a thing? I just want people to understand that this really isn't a fragmentation of the community and most certainly not a sub-set of Pattern Lab-ers trying to revolt.

Here's my take (and feel free to chime in / ding me if this isn't quite right):

1. 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.

2. 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.

3. 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?

4. 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.

Make sense?

[EvanLovely]

I totally agree with what you just said and think it's important to have as a statement to the community. So this doesn't get lost later, I think we should take what you just wrote on the second half and put it on the website; perhaps under a FAQ? I pulled this out and put it up on the website repo: https://github.com/drupal-pattern-lab/drupal-pattern-lab.github.io/pull/13

[EvanLovely]

For some of the comments in response to @cybtachyon around how to add the Drupal specific pieces on top of the Twig Edition of PL I've kicked off a new discussion here: #5

[EvanLovely]

OK; this is DONE! We've got a fork of the Twig Edition that points to all of our forks of it's dependencies. I've got the readme up to date as well.

https://github.com/drupal-pattern-lab/edition-php-twig-standard

Should this issue be closed as we've discussed the best Pattern Lab to support?

[sghoweri]

@EvanLovely I vote closing this out.

We've got an direction to run with, an updated edition that's all wired up and ready to go, and some FAQs for future reference as to why the heck all this is even a thing. CHECK, CHECK, and CHECK

[EvanLovely]

@evanmwillhite gives the 👍 too – closing this discussion down!