At DrupalCon Baltimore, the Drupal Pattern Lab working group was created to improve the existing tools and installations available for working with Pattern Lab as it relates to Drupal projects and to provide clear instructions for getting started and best practices for working through the different challenges with this approach. This session specifically is a continuation of DrupalCon Baltimore BoF [1].

The ideas behind the growing Design System craze are incredibly appealing -- a blissful Atomic Design-driven utopia of thoughtfully maintained and curated UI Components that power your digital web properties... Just take Pattern Lab, wire it up to Drupal 8 and we're good, right?

Unfortunately, some of the challenges (and day-to-day decisions) you might encounter when building out your own in-house Design System / Pattern Library aren't that widely discussed. Things like:

• Organizing your code as a single monolithic repository (mono repo) vs several separate standalone repos * Design system dependency management (aka NPM vs Composer hell)
• Managing releases and how to not break all the things
• Keeping the components in your system, especially the ones you've already shipped, in sync
• Documentation and testing your Design System when deadlines are looming

The goal for this session is to shed some light on a number of the growing challenges -- and discuss potential solutions -- encountered when you try to chase the Holy Grail of front-end/back-end development and realize just how hard it is to get there.

[1] https://events.drupal.org/baltimore2017/bofs/design-systems-are-hard