Make Pattern Lab Configurable via a .patternlabrc vs patternlab-config.json and ./config/config.yml

[cybtachyon]

Summary:

• Add support for a .patternlabrc config override file
• Add support for using Pattern Lab in a subdirectory, with the paths/libraries in a separate directory

Benefits:

• Eases use against an existing pattern library newly adopting Pattern Lab as a dev tool
• Eases use as a composer dependency instead of as embedded code

To Do:

• Validate use case with community
• Consider multiple sub-issues vs single issue patch
• Add patch for .patternlabrc and subdirectory usage
• Review & Test

There is a use case for Pattern Lab where a user already has an existing pattern library. Usually, the differences are on the smaller, but have enough existing dependencies to make refactoring for use with Pattern Lab to be impractical. Pattern Lab is a highly useful development tool, but bringing it into an pre-existing pattern library team’s workflow is more arduous than it could be. Typically, the user would need to fork an existing Pattern Engine and modify it to consume their current library.

Our proposal is that a common set of variables that change from library to library are configurable outside the Pattern Lab directory, perhaps with a .patternlabrc file. This file would be picked up when a Pattern Lab variant is installed and is run against the library as a dependency from the vendor directory or elsewhere. This allows config.yml to remain as default settings and have a project set overrides for easier inclusion into an existing workflow & project repo.

Some suggested settings:

• patternEngine - This configures the engine being used for the pattern library. Options would be overrides specific to each engine's config.yml.
• paths - This is an array configuring how Patterns are organized in the library. It should include support for shorthand (the default “atomic” as well as maybe some other common configurations) as well as an array hierarchy describing the directories and their relationships as in patternlab-config.json. In addition, the root should be configurable in addition to "source" and "public" to allow running Pattern Lab from a sub-directory.
• ordering - Configures whether Pattern Lab orders patterns by the default "filename", or by "header" or by "doc" where Pattern Lab would look in the pattern comments/documentation markdown file for style guide: components.1-button etc. to organize the patterns.

Paths to resources should also be configurable to a "pattern" or "component" constant, where Pattern Lab looks in each component's directory for the relevant resource instead of a separate subdirectory. Many existing pattern libraries keep all relevant component files in the same subdirectory.

This issue is a part of a series to fold functionality present in the nearly identical tool PatternKit in an effort to coalesce the development communities and deprecate PatternKit in favor of Pattern Lab. We plan on moving forwards with development starting August 21st.

Related Reading:

• http://patternlab.io/docs/advanced-config-options.html
• Discuss Starter Kits: What Structure / Partials should be in the "core" starterkit vs our unique kits? drupal-pattern-lab/roadmap#6 (comment)
• http://ui-patterns.readthedocs.io/en/8.x-1.x/content/patterns-definition.html#override-patterns-behavior
• Expand StarterKit Download Options #63
• Config Options for Plugins Should Automatically Get Scoped by PL #57
• Options for Subtype and Pattern docs/config #48
• https://github.com/PatternBuilder
• Add a Sample Engine with Schema Support to Pattern Lab #117

[cybtachyon]

Noting that if accepted we would also need a PR to https://github.com/pattern-lab/the-spec/ to update the spec.

[cybtachyon]

Closing in favor of pattern-lab/patternlab-node#999

[sghoweri]

Thanks! Excited to get this in place!