Repository navigation
Allow src/PatternData/Rules to be Configurable. #11
Description
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.
Activity
#11: Allow users to configure which Pattern Data Rules are used
sghoweri commentedon Jul 14, 2017
@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:
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_componentsfolder. Why not tweak that to allow for adding additional rules as well? @EvanLovely thoughts?And:
sghoweri commentedon Jul 14, 2017
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 commentedon Jul 14, 2017
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 commentedon Jul 14, 2017
Also, thanks for the contribution @christophersmith262 !! 🎉
sghoweri commentedon Sep 2, 2017
@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.jsonsuffix 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?
Working POC of optionally allowing default Pattern Lab rules to be di…