Question: What is the suggested workflow when dealing with multiple in-progress projects?

[chris-dura]

So, first of all, I'm more designer than developer, but I am familiar and efficient with all the typical front-end-y tools like git and gemfiles and node, etc.

Anyway, in an ideal world the pattern library would be designed, "defined" and delivered before development even started. However, I'm dealing with several large projects at the moment that are already deep into development, and I'd like to generate some pattern libraries for these projects.

It's not readily apparent to me the best way to go about using Pattern Lab with current projects. A lot of the other tools out there that automate styleguide creation are typically some sort of package (Ruby Gem or Node Module) that is installed "inline" with the actual project's development codebase. So, essentially the developers would generate styleguide documentation just like they would lint the code, usually through some gulp or grunt task, as an example.

However, just reading through your Pattern Lab documentation and the vanilla example, my first impression is that I would end up cloning (forking?) the patternlab-php.git repo for each of my projects and I would end up with something like this:

projects/
|
├── my-project/
|   ├── templates/
|   |   └── widget-pattern.html
|   └── sass/
|       └── widget-pattern.scss
|
├── pattern-lab-for-my-project/
|   └── source/
|       ├── _patterns/.../
|       |   └── widget-pattern.mustache
|       └── css/scss/objects/
|           └── widget-pattern.scss
|
├── my-other-project/
|   ├── templates/
|   |   └── foo-pattern.html
|   └── sass/
|       └── foo-pattern.scss
|
└── pattern-lab-for-my-other-project/
    └── source/
        ├── _patterns/.../
        |   └── foo-pattern.mustache
        └── css/scss/objects/
            └── foo-pattern.scss

I'd much rather not have to keep the styles/templates in-sync between two different directories. Even in a typical scenario where the pattern library was fully complete before development started, what is the workflow when, midway through a project, the product owner decides they want a button to be blue, instead of green? I'd have to change it in two places. I'm a little less concerned about the pattern templates but depending on their complexity, they could also represent a pain to keep sync'd.

Is there a better or recommended way of dealing with this?

[chris-dura]

Well, so it occured to me to just clone the patternlab-php repo into the actual working project's root, so I ended up with this:

projects/
|
└── my-project/
    ├── patternlab-php/
    |   └── source/
    |       ├── _patterns/.../
    |       |   └── widget-pattern.mustache
    |       └── css/scss/objects/
    |           └── widget-pattern.scss
    ├── templates/
    |   └── widget-pattern.html
    └── sass/
        └── widget-pattern.scss

which, would have been at least marginally better than the above. But, while running generateSite.command seemed to work fine the first time, it didn't pick up subsequent changes to the *.mustache files.

[bmuenzenmeyer]

@chris-dura For what it's worth - this is what I do and it works fine - but I can only speak from the patternlab node standpoint.

I wrote a bit about this technique here: Using Pattern Lab to Design, Build and Maintain a Website

[chris-dura]

Thanks @bmuenzenmeyer ... maybe I'll looking into switching to patternlab-node, as I'm still experiencing problems with the cloned patternlab-php instance within the project not picking up changes to templates.

[vlrprbttst]

+1 suggestions about a proper workflow using patternlab and how to have it become a living styleguide would be appreciated!

[bradfrost]

Hey @chris-dura,
Thanks for taking the time to write this up.

Anyway, in an ideal world the pattern library would be designed, "defined" and delivered before development even started.

A big part of what I harp on about is how frontend development should be treated as an integral part of the design process. The final frontend and underlying design system should be created in a cross-disciplinary way.

Now, I recognize that's probably not what you're talking about. It sounds like you have some projects that are already in the implementation phase before the dust has settled on the frontend UI. This can be challenging as it requires some back-and-forth between the production environment and design environment (which may include Pattern Lab). I've worked on quite a few projects where I'm on the hook for the frontend code and other teams plug it into a CMS. In my experience, there's plenty of work that can be done in tandem, and communication between these teams is far more effective than any tool can provide.

That being said, there are different approaches for Keeping Pattern Libraries In Sync and Achieving the Holy Grail. Which approach you use largely depends on your set up, workflow, organization, and tools.

In my own workflow, I set up Pattern Lab adjacent to the production environment. I use Grunt with Pattern Lab to compile CSS, minify JS, etc. I also use grunt-copy to copy the compiled CSS and JavaScript over into the production environment.

As it turns out, keeping CSS and JavaScript in sync is easy. It's the templated markup that's the real issue here. By default, Pattern Lab uses Mustache as its templating engine. If your CMS uses Mustache, then keeping patterns in sync should be the same as keeping CSS & JS in sync. BUT, if the production environment uses a different templating engine (or no templating engine as in Wordpress's case), there's an extra step involved to get markup from Pattern Lab into the production environment.

For what it's worth, @dmolsen is addressing exactly this with the new version of Pattern Lab. By decoupling the templating engine from Pattern Lab's core and UI, teams can use their templating engine of choice within Pattern Lab, making it far easier to keep everything in sync. For instance, Drupal developers can use the Twig pattern engine to keep Drupal and Pattern Lab in sync. I've since talked to teams who use Pattern Lab (running Twig) inside their Drupal theme to great success.

As far as my longterm maintenance goes, Pattern Lab always remains the primary development environment. Any and all frontend changes go through Pattern Lab first, even for projects that have already been launched. This is more a workflow issue than a tool issue, but it requires a fundamental shift in thinking:

I talk more about this elsewhere and I'm about to start writing on this exact topic in my book. Hopefully this helps a little.