Allowing Pattern State to be set in MD files front matter.

[EvanLovely]

Currently, to set Pattern State one needs to rename button.twig to button@inprogress.twig. This change brings the much better approach from the Node version (while keeping the old behavior), that let's one create a file button.md that contains:

---
state: inprogress
---

/cc @sghoweri

[sghoweri]

Hey @EvanLovely crazy idea. If we had an array of all the special Pattern Lab keys (state, patternType, patternSubType, etc) couldn't we expose the whole kit and caboodle to markdown files to let anything get configured here?

I'm already doing something virtually identical in #125...

[aleksip]

@sghoweri @EvanLovely I think documentation and configuration are two sides of the same coin: we need to think of them together, but they still probably need different files?

Also, this reminds me of #28 and components.json! Would be great to get those ideas moving again! :)

Edit: Ah, looking at #125 I now get that patternType etc. would only affect how the documentation is displayed, so it would not be configuration in that sense?

[sghoweri]

Edit: Ah, looking at #125 I now get that patternType etc. would only affect how the documentation is displayed, so it would not be configuration in that sense?

@aleksip After looking into Fractal as a source of inspiration, I've actually been toying around with the idea of having pretty much any file type be mappable to a particular purpose via a prefixed file extension.

For example, given a button component and the various bits of data that could be associated with it (and #124 ) why not let the file spell out it's intended purpose?

Docs

button.docs.md button.docs.html button.docs.twig button.docs.js README.md --> patternType: button

Schema

button.schema.json button.schema.yml button.schema.js

Data

button.data.json button.data.yml button.data.js?

Config

button.config.md button.config.yml button.config.json button.config.js package.json --> patternType: button

JS or SCSS

Package.json key?

[EvanLovely]

It’s really meta info we are talking about with pattern docs & pattern configuration, right? I like the idea of having markdown with front matter being a config setting for meta info related to a pattern. It’s a convention that is in enough to the PL spec & approach from both PHP & JS that I don’t want to implement the extension suggestion - even though I really like it! Perhaps a 3.x option.

Let’s continue conversation over in #125 as this is a closed issue. I’ve added that issue and #28 to the PHP Roadmap