Support multiple pattern directories

[bmuenzenmeyer]

Capturing some notes from Target folks:

If confg.patterns.source accepted an array of patterns directories, one might be able to inherit shared / base patterns from a separate repository directory and build product-specific pattern libraries atop them.

Questions

1. What problems does this make for file watches, if any? Look into https://github.com/sindresorhus/gulp-changed
2. Does the algorithm even need to change in any significant way? Seems like all one would have to do is tweak pattern_assembler.processPatternIterative() and pattern_assembler.processPatternRecursive() to go through the array instead of one directory.

[geoffp]

1. Good question, but I think if the main use case is a larger, product-specific pattern lab that require()s another that provides some atoms it needs, for example, then I can imagine one of two things:
   1. As long as the require()d one has an API that can hand us a list of absolute paths to watch, we should be okay.
   2. We can assume that the require()d one is static, and we therefore don't need to watch it.
2. I kind of don't think so -- like you said, we might just be able to run the whole process twice, in the order paths are provided by the array. In the case of duplicate pattern names, patterns from libraries later in the array could override those provided earlier, which might take some tweaking, but that sounds like no big deal to me.

[lostsatellites]

I like this approach, a few questions though which I could see being relevant at least in the way we're thinking through multi-site (think theme-specific rather than product-specific) …

1. Would each product-specific pattern directory also have the ability to have unique pattern-header-footer directories to link to different css/js dependencies?
2. If a path later in the array has duplicate patterns would they have to follow the same numbering pattern in order to be overridden? How would you handle an instance where you may want to remove patterns from libraries later in the array? Would a per-pattern directory config make sense on whether you're merging, removing or completely replacing a pattern directory?

[geoffp]

1. Yeah! Since Pattern Lab / Node 1.2, we use meta-patterns to put JS&CSS places, and those are invisible patterns that are a part of your own pattern tree.
2. There are three excellent questions here.
   1. The numbering scheme has started to become problematic for my team as well, but I see no reason in principle why we couldn't override same-named but differently-numbered patterns, I'm sure it would just be extra work.
   2. To exclude patterns from inherited libraries, maybe we could do that in patternlab-config.json.
   3. That's also not a bad idea. Maybe some convention like for 00-pattern.mustache, 00-pattern.meta.json, with config inside.

[bmuenzenmeyer]

Unrelated to the above topics - which are important - I wanted to get down a paper another approach that came on the back of support for starterkits.

Starterkits, when used as a base for derivative development, could be consumed in one of two ways:

• imported directly into source, so as to be mutable per instance of PL. This would satisfy the needs of agencies that might have a foundation for every client project. This seems to align with the current starterkit strategy as it's built and will be built for PL/Node 2.0.0
• referenced as part of an immutable array of base starterkits, which PL/Node will loop through to pick up as patterns, before processing source patterns / assets. This would satisfy the use case of a base product family or design system. Themes? perhaps. I need to think about if that even applies. This would likely be a PL/Node 2.X feature, if not something we need to bless with Dave and Brad conceptually altogether as the evolved form/application of starterkits

cc @geoffp since we were talking about this today, but I hadn't really worked through the whole reference thing.

[dmolsen]

👍 to "referenced." This is the feedback I've gotten as well.

[geoffp]

👍 to referenced from me too. This is pretty much the vision that we have over here for our ideal thing. It would let us keep our "base" patterns, which are intended to be shared with multiple product teams, under source control separately from each team's more product-specific patterns. And it provides a clear upgrade path for base patterns, widget sets, or whatever without having to dig them all out of your source directory.

[bmuenzenmeyer]

Cool -
import should be wrapped up in no time flat for PL/Node 2.0.0-alpha and align with the current way of doing things in PL/PHP (afaik), with a early 2.X goal adding reference as an option.

[bramsmulders]

Addressed in #645

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.