Added separated pattern-folder support

[JosefBredereck]

Added the functionality to separate the patterns from each other by adding the support for a capsulation folder by pattern. Also added tests.

Summary of changes:

This change will allow to provide a folder stucture like this

[patternType]/[patternSubtype]/[patternNameFolder]/[patternName].[patternExtension]
[patternType]/[patternNameFolder]/[patternName].[patternExtension]
[patternNameFolder]/[patternName].[patternExtension]

but also the old way (so that we stay backward compatible)

[patternType]/[patternSubtype]/[patternName].[patternExtension]
[patternType]/[patternName].[patternExtension]
[patternName].[patternExtension]

With a directory structure of that example:

- molecules/
  - blocks/
    - media-block/
      - media-block.md
      - media-block.mustache
    - button/
      - button.md
      - button.mustache
      - button~primary.json
    - jumbotron.md
    - jumbotron.mustache
  - heading/
    - heading.md
    - heading.mustache
  - link.mustache
  - link.md
- card/
  - card.md
  - card.mustache
...

which will result into

<ol>
  <li>Molecules
    <ol>
      <li>Blocks
        <ol>
          <li>Media Block</li>
          <li>Button</li>
          <li>Button Primary</li>
          <li>Jumbotron</li>
        </ol>
      </li>
      <li>Heading</li>
      <li>Link</li>
    </ol>
  </li>
  <li>Card</li>
</ol>

[sghoweri]

Wait - PL Node didn't previously allow grouping together related component files like this? 😅

_patterns/01-atoms/buttons/button.twig
_patterns/01-atoms/buttons/button.md
_patterns/01-atoms/buttons/button.json

[sghoweri]

Have we tested / confirmed that this works with folders that have number prefixes to adjust the ordering (ex. _patterns/01-atoms/10-buttons/button.md, _patterns/01-atoms/20-icons/icon.md, etc)?

[JosefBredereck]

Wait - PL Node didn't previously allow grouping together related component files like this? 😅

_patterns/01-atoms/buttons/button.twig
_patterns/01-atoms/buttons/button.md
_patterns/01-atoms/buttons/button.json

This is nesting one step deeper. buttons/button.(extensions) works as desired. But If you put your button under the form and you want to do it like this 05-atoms/10-form/05-button/05-button.(extensions). It won't work without this change.

Have we tested / confirmed that this works with folders that have number prefixes to adjust the ordering (ex. _patterns/01-atoms/10-buttons/button.md, _patterns/01-atoms/20-icons/icon.md, etc)?

With the suggested change from @engelfrost, it won't work that way, you have to name your files with the number prefix too. ../20-icon/20-icon.(extensions)

[engelfrost]

I haven't given much thought to the idea itself, I don't consider myself the right person to balance the benefits of the feature with the code complexity and design philosophy.

But this I think illustrates the use case:

Instead of seeing this

I could see this

[JosefBredereck]

Exactly and the first image shows my trouble all the time. To much files. I know it differently from Angular where you have your components in different folders separated from each other. (That's the second image)

[sghoweri]

Exactly and the first image shows my trouble all the time. To much files. I know it differently from Angular where you have your components in different folders separated from each other. (That's the second image)

I totally agree.

The only issue I have here (and it’s a really big one) is requiring children of the parent component folder (ex. files in the 70-big-radio folder) to have the exact same number prefix as the parent container.

The whole point of the number prefixes is to be able to easily change the order that patterns show up, not be a unique identifier to know X children are related to Y parent.

Given that + this being a major breaking change for folks using PL PHP looking to migrate over to PL Node (once the new PHP Twig Renderer ships), how hard would it be to get this nesting support in place without requiring the nested files to share the same number prefix?

[JosefBredereck]

The only issue I have here (and it’s a really big one) is requiring children of the parent component folder (ex. files in the 70-big-radio folder) to have the exact same number prefix as the parent container.

In my first idea, it wasn't necessary to have the same number prefix but it would lead to a problem with the subgroup of the pattern. An idea maybe would be if the containing folder ends with the same name as the pattern has.

05-atoms/05-buttons/00-button/button.(extensions) would work without error and 05-atoms/05-buttons/button.(extensions) won't make any trouble also, because buttons end with s. But that's risky. because you can have something like 05-atoms/05-from/form.(extensions) and wanted form to be a folder for inputs, forms, and other stuff.

The whole point of the number prefixes is to be able to easily change the order that patterns show up, not be a unique identifier to know X children are related to Y parent.

If you want to change the order you have to rename all files today also, haven't you?

Given that + this being a major breaking change for folks using PL PHP looking to migrate over to PL Node (once the new PHP Twig Renderer ships), how hard would it be to get this nesting support in place without requiring the nested files to share the same number prefix?

The old way still exists. So migrating shouldn't be a problem. Also, upgrading from PL 2.3 to PL 3.0 should work easily.

[engelfrost]

05-atoms/05-buttons/00-button/button.(extensions) would work without error and 05-atoms/05-buttons/button.(extensions) won't make any trouble also, because buttons end with s.

What if the name has to match exactly, but you are required to drop the numbering on the files?

05-atoms/05-buttons/00-button/button.(extensions) // Correct
atoms/buttons/button/button.(extensions) // Correct

Files that don't follow the naming scheme would trigger warnings and should not be rendered IMO:

05-atoms/05-buttons/00-buttons/button.(extensions) // Incorrect (notice the "s")
05-atoms/05-buttons/00-button/00-button.(extensions) // Incorrect, or at least unnecessary

this being a major breaking change for folks using PL PHP

I have very little knowledge about the PHP version, what is it that would be broken?

[JosefBredereck]

I will implement that because I like it much more than the additional numbering in the subfolder.