Allow declaration of template path in SDC

Curious how this approach compatible with front matter 📌 Create TemplateDiscovery for plugin managers to use Needs review

I am not sure about this one. I see where you are coming from, you want to avoid having a dummy component template that only has an include of the upstream component, by moving it to the YML.

I think having it in the .twig file is better because is not a new thing to learn. A dev new to SDC opens the template and sees a common Twig tag (include, embed, extend, ...) and knows what is going on. If it's in the YML file, they are puzzled by the missing template file that should be there.

I have updated the issue summary to remove references to "distinct template by variant". We understand it can be a messy implementation for an uncommon use case, and we can get rid of this requirement.

I think having it in the .twig file is better because is not a new thing to learn. A dev new to SDC opens the template and sees a common Twig tag (include, embed, extend, ...) and knows what is going on. If it's in the YML file, they are puzzled by the missing template file that should be there.

Using a dummy component template is a workaround, indeed. But I am proposing to make template property settable in the YAML in order to:

• avoid a redirection layer
• be able to list components explicitely using foreign templates (instead of hiding this usage in the Twig code) . Identifying them is important because we agree this is not the best practice to promote. We are targeting single components.

The template property exists anyway, and it will be explicitly used by alternative discovery 📌 Make SDC extensible Active , i.e. loading SDC components from non SDC formats (for example,loading SDC components from the legacy UI Patterns 1.x format, or from Patterns Labs).

Any new thoughts on this one? And how it relates to:

✨ make SDC respect *.info.yml namespaces Active

Hi Kristen,

Because we (the UI Suite team) got the feeling this issue was controversial, we reorganized the UI Patterns 2.x project to not rely on this any more.

I still personally thing it would be a good feature, but not something to fight for.

No problem. I don’t need it but stumbled here when trying to see if I could get rid of using the components module.