Discussion: Add ability to reference starterkits instead of importing them

[bmuenzenmeyer]

As a design system creator, I want other product teams to have the ability to inherit base patterns and assets from an upstream, unchangeable starterkit, so that they may build derivative experiences off of a single source of truth managed by me.

---

As described in these comments, starterkits as we currently know them are really just copy paste helpers for the source/* directory patterns and assets. This is useful for, say, an agency that wants all their client projects to start from a base, and then send that instance of Pattern Lab to the client when done. But it falls down a bit when Pattern Lab is used as the foundation of a design system, where a team may want to design and build many products from a shared baseline experience.

@geoffp at Target can elaborate on any use cases I missed.

What is proposed here would be a core or edition change that would allow starterkits to be referenced instead of wholesale imported, if desired. The current behavior should still be supported too. Referencing starterkits before processing anything in source/ would load the base patterns first, allow them to be referenced as partials by source/ patterns, but keep them out of version control, since they'd be in some vendor / ignored space instead of co-mingled with source/. Patterns are probably simpler to do this for than the other assets, which may require edition changes.

The timeline for this feature is not critical for 2.0.0 release, but would be a nice addition to Pattern Lab capabilities.

Tagging core and spec-enhancement because this starterkit reference enhancement is suggested for all platforms.

Voting is postponed until further notice.

/cc @pattern-lab/voting-members

[dmolsen]

I'm generally ok with this but have been trying to work through the mechanics of making sourceDir and/or patternDir an array in the config is fine. I think things like _meta/ and merge priority on _data are where it gets a little trickier. On PL/PHP's side I'm already doing some automated stuff on install so I guess I need an opt-out so things don't get moved for certain StarterKits. It seems like this model would take two per project (which is fine). One would be a skeleton just to get source/ set-up and then load the second with "all the things" and register that it exists.

Could you offer some more details on how you'd expect how a project would be initialized and how to handle something like _meta/? It doesn't seem like that could be immutable. Do these items need to show in the nav?

Would this extend to individual patterns needing to be added to the sourceDir array? I could see someone wanting to bend it that way.

[bmuenzenmeyer]

I think the first couple comments in that linked issue point in the wrong direction.

I want to respond with a detailed breakdown of how this would work and address the concerns you bring up, in addition to some of the original thread's, but feel it would take a while. Since I see this as a 2.1.0 or greater feature, with your permission @dmolsen, I'd like to extend or remove the voting aspect of this issue until I've made a stronger case.

Are you okay with that?

[dmolsen]

@bmuenzenmeyer -

Yup. Removing the voting requirement would be a good step. I think the devil is in the details on this one.

[sghoweri]

@dmolsen @bmuenzenmeyer @bradfrost I'd imagine that this use case of referencing Starterkits (as opposed to importing -- ala copying and pasting) is very closely related to the conversation on installing components, yes?

The reason I'm asking is that I'm finding myself hitting the exact same design system scalability issues right now trying to get a curated set of Pattern Lab-built Twig components to be shareable / extendable across multiple Drupal 8 sites and wanted to get a sense on how I can help solve this overarching issue.

[ringods]

For the NodeJS version of PatternLab, this is how I would see it working:

• starterkits are plain NPM packages
• starterkits are tagged with patternlab and starterkit to not require a specific naming scheme and for easy search on npmjs.com
• a starterkit can depend on another starterkit if the patterns build upon each other
• starterkits are detected at runtime by PL by searching the list of installed packages with the above tags
• the load order of starterkits is a directed graph keeping the NPM package dependencies
• if a starterkit contains e.g. custom handlebars helpers, these helpers are exposed and reusable in projects using that starterkit