Problem/Motivation

SDC has been working great on my projects, and I have little by little built a library of components.

However, now if I'd like to start a project from scratch and reuse them, it means I need to create a new theme and pretty much copy all of the definitions.

I know that I could create a theme or module and them have my components there, but it kind of feels like an unnecesary / annoying requirement.

Proposed resolution

I have 2 ideas in mind:

  • Since the Recipes initiative allows to have recipes that live outside Drupal, I was thinking if it makes sense to do something similar for SDC. Have them live outside and be discovered.
  • We could have a components folder, similar to what we have with modules or themes, where we could have contrib SDC and custom SDC. This would require writing a new installer type, but then these could be shared in packagist in a way. But then users could just require the ones they need for their projects.

API changes

Change the discovery mechanism for SDC.

First steps are

  1. Find out who needs to give sign off
  2. Get sign off on the initial idea
  3. Figure out technical implantation (this will require DA staff as well as core changes)

Issue fork drupal-3476854

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

alemadlei created an issue. See original summary.

mherchel’s picture

mherchel
he/him
Primary language English
Location Gainesville, FL, US
commented
Version: 10.4.x-dev » 11.x-dev
Issue summary: View changes

I want to give a hearty +100 to this. It's something that I've been thinking about for a while.

Updating IS with next steps

  1. Find out who needs to give sign off
  2. Get sign off on the initial idea
  3. Figure out technical implantation (this will require DA staff as well as core changes)
thejimbirch’s picture

thejimbirch commented
Title: SDC: Sharing trough composer and discovery mechanism » SDC: Sharing through composer and discovery mechanism

This has been asked of us many times in the recipes realm. Recipes themselves don't have anything to do with Single Directory Components (SDC), but could require them using the recipe's composer.json file. The dependency for that requirement could be unpacked to the project's composer.json file so it would be have like a contrib project and would be updatable from the source.

I assume you wouldn't need to do anything to SDCs to make that work. Just make them available from a composer or asset packagist.

If Drupal defines a new package type, say drupal-sdc, you would then want to open an issue with composer/installers to add that package type. Here is the drupal-recipe pull request for reference.

You would then need to define a place to put the SDCs. With recipes, we did that by adding an installer-path to the drupal/recommended-project and drupal/legacy-project composer templates.

"Change the discovery mechanism for SDC." sounds like the perfect description for that last step and far from my expertise to comment on.

Love this idea!

sea2709’s picture

sea2709 commented

I see that many components using variables from the theme, especially theme's colors, font styles, etc.. Just wondering, if components are something separate from the theme, will we need to have some guidelines or standards about how to define variables or how to pass variables from theme to components. Just want to share my thoughts!

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Hey sea2709,

That's one way to implement it, however, you could also try to define broad CSS variables with default values or use CSS layers so that they are easy to override.

Some people also use Tailwind when defining their components, and those clases are standardized elsewhere.

sea2709’s picture

sea2709 commented

you could also try to define broad CSS variables with default values or use CSS layers so that they are easy to override.

Yeah, this is what I meant, we need to have a guidelines about how to build outside / dependent components to make them work well with themes later on.

One more thing came across my mind is when we have a set of base components and apply these components for different projects. So there might be a chance that we want to add more properties, more slots for components. From what I understand, we don't have this ability at this moment, the way we do is to replace a component by another component in case we want to extend it.

(Just realize that this comment might not be in the scope of this issue which is about the discovery mechanism 😅)

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

I know that I could create a theme or module and them have my components there, but it kind of feels like an unnecesary / annoying requirement.

When we were on the drawing board, this was considered. However it was discarded because Drupal does not have a way to deal with name collisions in composer packages. It does however have one for modules. This way we were able to reliably determine the component prefix.

The important question here is: why does it feel like an unnecesary / annoying requirement?

I'd like to clarify this part of the IS before moving forward with this.

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Hi e0ipso,

So my train of though is as follows:

* The way I write SDC I try to avoid dependency to other Drupal things. I know they are flexible enough so that you can build them any way you want, but I try to have them be completly agnostic regarding what environment they are in (my larger goal is that maybe I could use them on Wordpress or Laravel projects in the future).

* Having a theme wrapper or a module wrapper to just include a components folder kind of feels (and I know this is my own opinion) unncesesary because you are not adding anything else other than the components folder.

* Recipes right now are something that don't require a module or theme to be created. They exist and they can be used in a project by running the script. Related to recipes, checking the Drupal source, once installed recipes have their own folders, no need for modules or themes. So I feel kind of envious towards that, and think that SDCs could also have their own folder for contrib and custom. That way they can be shared trough composer or custom repositories.

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Yesterday I did this presentation: https://www.youtube.com/watch?v=hAASS2tyVkQ

This is the Shareable SDC module, https://www.drupal.org/project/shareable_sdc and this is the sample repository used for the live stream https://github.com/AleMadLei/sdc-styleguide-ai-assisted/tree/shareable-s... (it runs on top of DDEV, has a database backup and the composer.json with all the requirements to be able to load SDCs through composer (the video explains better).

These are some sample components that were built:

* Details: https://github.com/AleMadLei/details/
* Sample Card: https://github.com/AleMadLei/sample-card
* SDC Prueba: https://github.com/andresalvarez2018/sdc_prueba

This uses the composer installer extender, defines a new installer type and path for components and adds repositories with sdcs.

pdureau’s picture

pdureau commented

hi,

We may have a better implementation and gain more traction if we propose something more generic than SDC: the "single plugin Drupal extension", alongside modules, themes and profiles (and recipe, I guess).

As soon as a plugin has a YAML discovery, it can be packaged as a single shareable unit.

The information usually in info.yml would be split between:

  • new properties in the YAML of the plugin definition (if necessary)
  • the composer.json file

So, all those difficult challenges (distribution, dependency management, naming conflicts, metadata....) will be solved as a global Drupal subject

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Hey pdureau,

I'm interested in the idea, but what would next steps be?

How can I help this get more traction?

freddy rodriguez’s picture

freddy rodriguez
Location Bogotá
commented

Hello,

There are some definition about this initiative?

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Hey Freddy, not sure yet regarding an official path.

But you are welcomed to try what I shared on #9

meeni_dhobale made their first commit to this issue’s fork.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

alemadlei’s picture

alemadlei
Primary language Spanish
commented

Just a quick update for this.

I pushed rc2 last night https://www.drupal.org/project/shareable_sdc and got it to work for Drupal Canvas (after adding examples to my sdcs).

I will begin to create a repo of basic components, to test that it is even more viable for a future option.