Allow src/PatternData/Rules to be Configurable.

[christophersmith262]

By default, Pattern Lab is pretty opinionated about the folder structure for source/_patterns folder. This can lead to issues when packaging components in a way Pattern Lab doesn't expect.

For example:

source/_patterns/atoms/
  button/
    button.twig
    js/
      index.js
    sass/
      button.scss
    tests/
      test.js

Leads to several undesired component sub types getting created when Pattern Lab is compiled:

ATOMS / BUTTON / JS ATOMS / BUTTON / SASS ATOMS / BUTTON / TESTS

When what we really want is just the: ATOMS / BUTTON component.

Here's a list of the default rules provided by Pattern Lab:

PatternLab\PatternData\Rules\DocumentationRule
PatternLab\PatternData\Rules\PatternInfoListItemsRule
PatternLab\PatternData\Rules\PatternInfoRule
PatternLab\PatternData\Rules\PatternRule
PatternLab\PatternData\Rules\PatternSubtypeRule
PatternLab\PatternData\Rules\PatternTypeRule
PatternLab\PatternData\Rules\PseudoPatternRule

The use of these rules is currently hard coded in: https://github.com/drupal-pattern-lab/patternlab-php-core/blob/master/src/PatternLab/PatternData.php#L393

I would propose allowing this to be configured in config/config.yml:

twigTagExt: tag.php
twigTestExt: test.php
enabledPatternRules:
  - PatternLab\PatternData\Rules\DocumentationRule
  - PatternLab\PatternData\Rules\PatternInfoListItemsRule
  - PatternLab\PatternData\Rules\PatternInfoRule
  - PatternLab\PatternData\Rules\PatternRule
  - CustomRules\PatternSubtypeFilterRule
  - PatternLab\PatternData\Rules\PatternTypeRule
  - PatternLab\PatternData\Rules\PseudoPatternRule
...

This would prevent users from having to perform hacky file system magic (currently we do this with a gulp task creating symlinks galore) in order to get their existing component libraries running in Pattern Lab.

[sghoweri]

@christophersmith262 I’d propose reversing the logic so that out of the box all default rules are enabled (ex. if someone didn’t update their config.yml) so this wouldn’t introduce a breaking change to Pattern Lab. That way you’d specify just the specific rules to turn off:

disabledPatternRules:
  - PatternLab\PatternData\Rules\DocumentationRule
  - PatternLab\PatternData\Rules\PatternInfoListItemsRule
  - PatternLab\PatternData\Rules\PatternInfoRule
  - PatternLab\PatternData\Rules\PatternRule
  - CustomRules\PatternSubtypeFilterRule
  - PatternLab\PatternData\Rules\PatternTypeRule
  - PatternLab\PatternData\Rules\PseudoPatternRule
...

If we’re going to run with this, I’d propose also including a way to fold in additional rules (for CSS files, JSON schemas, alternative folder structures, related links, etc etc) - somewhat similar to what Fractal already does.

For example, we already have a source\twig_components folder. Why not tweak that to allow for adding additional rules as well? @EvanLovely thoughts?

./source
└── extensions
    └── twig
    |    ├── functions
    |    ├── filters
    |    ├── tags
    |    └── tests
    └── rules
         └── CustomDocumentationRule.php

And:

extraPatternRules:
  - CustomDocumentationRule
...

[sghoweri]

Crap. Now I’m thinking, “Wouldn’t it be lovely if we could just point PL directly to our Twig Extensions folder being versioned and published by Lerna”, regardless on if it’s in the source folder or not...

[EvanLovely]

I'd like to see both the enabled and disabled settings available. That way we don't break backwards compatibility with people needing to add all the core rules to the enabled section (or if core adds a rule) and people can add their own custom rules (which couldn't happen if we just set up the disabled setting).

[EvanLovely]

Also, thanks for the contribution @christophersmith262 !! 🎉

[sghoweri]

@EvanLovely I think I'd like to take a crack at making some progress on this front.

Just in this past week or two I ended up coming up with a bunch of potential enhancements in how Pattern Lab processes markdown and external data (ex. allowing for embedded Twig templates in markdown files to get rendered and use the same data as patterns, allowing README.md files to be associated with a particular pattern via frontmatter, allowing external JSON data files to still be associated with a particular pattern - even if the JSON file has a pattern.somesuffix.json suffix on it, etc) however some of those feel a lot more like add-on extras that some people could get a lot of value out of but might be a bit too opinionated... maybe.

Thoughts?