search

pattern-lab / the-spec

The specification for implementing Pattern Lab in various languages. This way there can be common core functionality and common shared assets.
16 stars 3 forks source link

Discussion: Add ability to reference starterkits instead of importing them #17

Open bmuenzenmeyer opened 8 years ago

bmuenzenmeyer commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@bmuenzenmeyer -

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

sghoweri commented 8 years ago

@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 commented 5 years ago

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