Discuss Starter Kits: What Structure / Partials should be in the "core" starterkit vs our unique kits?

[finteractive]

With the default starter kit that's being worked on here https://github.com/drupal-pattern-lab/edition-php-twig-standard/ this comes with a pre-defined folder structure that is in my opinion confusing to Drupal folks as they both reserved terminology for Drupal themes/structures.

In Atomic Jargon

• Templates are page-level objects that place components into a layout
• Pages are specific instances of templates that show what a UI looks like with real representative content in place

My team has settled on Layouts (=Atomic Templates) & Mockups (=Atomic Pages) as the equivalent folders. There's less confusion compared to the default folders.

Questions

• Is the roadmap the right place to talk about what's in the core starterkit? Should I have posted this issue in some other place?
• Are we trying to get consensus on this kind of thing into the core? Or should my own preferences listed above be in my own starter kits loaded after the core starterkit?

[EvanLovely]

Just wanted to jump in here and say that I think this is a very important topic as it's what people see when they first open Pattern Lab, it's what enables so many different interpretations of that possible while still harnessing the same underlying codebase... and it's where we have lots of opportunities to improve how it's done.

• I think this roadmap is the perfect spot to ask a question that you don't know which repo it belongs on; that's one of the problems with a project split across so many repos. If it belongs elsewhere, we'll just move it over there or link to it.
• The good news is we can have several StarterKit suggestions that are presented to the end user to decide from after install. The kits added to these lines are what is asked. It takes the form of GitHubUser/Repo. Those currently still point to the upstream starter kits in the Pattern Lab Org. And I believe the first one doesn't even compile, so that needs to get fixed soon.

I think the choices are important as this is where things get very opinionated very quickly and that's a good thing.

I see these next steps being needed:

• [x] Point our Editions StarterKit suggestions to our StarterKits - done
• [x] Ensure both compile

I also think that simply having some docs (in readme, or docs folder, or on website) that show how to install a StarterKit in an existing site would be good as it'd let people try different ones out without having to do a complete re-install. This is the command that would do it:

php core/console --starterkit --install GitHubUser/REPO

If it was on the website, it'd be super awesome to have the demo hosted somewhere so one could see it as well.

To come back to your question, I think the place for these things for now is in your company's StarterKit. If you feel like it gets to a point that it's fleshed out and thorough, go ahead and put up a PR to have it be one of our StarterKit suggestions!

[cybtachyon]

I would also like to recommend that any partials (patterns/components etc.) that are shared are kept in a separate pattern library.

For example, a generic image partial, media item, HTML element with attributes, or other generic components would be best suited for their own repo so they can be used by other projects or implementations, or even dropped in favor of a user's own partials.

Partials that are Drupalisms or specific to this Drupal Pattern Lab project should remain in the base project repo.

This opinion is formed from the experience struggling to maintain a library of components that ended up being re-used on site after site, when the components were not in a central pattern library repo.