Single Directory Components module roadmap: the path to beta and stable

Updated the date to be more precise about how much time is left. About 1 month and a half to cross the finish line!

Updating issue summary to add the issue for Olivero to use SDC: 📌 Create new SDC component for Olivero (tabs) Postponed

Adding 📌 Move code from the experimental SDC module to core Fixed as stable blocker.

Adding 📌 [SDC] Validate and improve developer experience and helpfulness of error messages Active as stable blocker.

Adding 📌 [META] SDC: Improve and extend documentation Fixed as stable blocker.

Removing "Remove the experimental status" as a stable blocker. The plan is to fold SDC directly into core, and thus it will not be able to be experimental.

Adding 📌 If needed, create automated tests to validate SDC's use of Drupal escaping and Twig sandboxing Active as stable blocker.

Adding 📌 SDC: Prevent unwanted context passing with Twig include/embed functions Active as a non-stable blocker.

Adding 📌 Create SDC "Quick start" documentation / code Fixed as stable blocker.

Added a follow up derived from technical review.

Added another follow up from technical review.

Dedupe issue in the list.

Added a new follow up for the class_aliases.

Initial MR has been merged. The first big step is .

I created 📌 Mark SDC as beta so it can be included in 10.1 Fixed to discuss marking SDC as beta stability before 10.1.0-alpha1 is tagged. This will mean that SDC will be available as an experimental module in 10.1.

There was a video call meeting with the Front-end Framework Manager team where we went over each one of the remaining tickets. We confirmed that the tickets marked as stable blockers are indeed that, and not beta blockers.

The attendants to the meeting where:

• @lauriii
• @ckrina
• @bnjmnm
• @n0d_
• @mherchel
• @e0ipso

This was documented in comment #129 ✨ Add Single Directory Components as a new experimental module Fixed of ✨ Add Single Directory Components as a new experimental module Fixed , but referencing here for convenience.

Removing 📌 Move makePathRelative from SDC to the FileSystem component Closed: won't fix which we determined is "won't fix".

Added 📌 [PP-1] Remove schema references from contrib in SDC tests in core Postponed .

I found a bug while using the beta: 🐛 Unable to override library auto-definition to add external CSS & JS Fixed . There is a workaround listed in the issue.

Added an issue for a warning related to the locale module upon cache clears. I have only been able to reproduce this using Umami so far. 🐛 _locale_parse_js_file cannot open SDC JavaScript files Closed: works as designed

Updated the roadmap to add links to the meta issues to add components to Olivero and Umami, replacing the links to specific component migrations.

Changing target branch to 10.1.x.

Plan is to create a merge request here for 10.2.x and then create seperate issues per namespace or if needed per file so we can discuss where those classes should end up in core when the module exists experimental status.

Adding 🌱 [Meta] Convert core UI components to use single directory components Active

Adding 🐛 [SDC] Improve error handling during prop validation errors Fixed

Adding 🐛 Unhelpful error message with SDC when a optional variable is missing Closed: duplicate

✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed will require the promotion of justinrainbow/json-schema to a runtime dependency (currently require-dev). We'll need to vet the library in [], and it is unclear if we want to do so.

I don't think this should be a blocker for stability, but a nice-to-have.

I would love to have it as a runtime dependency. We had several folks who didn't realize that it needed to be installed for SDC to output helpful error messages. Having it as a runtime dependency would improve the DX.

I think the first steps towards stability are:

• 📌 Move code from the experimental SDC module to core Fixed
• 🌱 [META] Create Single Directory Components for the Umami theme Active

Added 📌 [SDC] Add a test for multiple *.component.yml in the same directory Active as non-blocking.

Adding 🐛 SDC Stylesheets are output in the wrong order (relating to normal libraries) Active as a stable blocker. Discussion in Slack at https://drupal.slack.com/archives/C4EDNHFGS/p1690469220405819

Added another stable blocker.

Added another stable blocker 📌 Allow other Twig node visitors to modify 'display_start' and 'display_end' Active . So great that people are trying this!

Added another stable blocker: 🐛 SDC componentMetadata does not take the right context when a component is extended Active .

There is now umami SDC components so removing it from stable blockers

Removing 🐛 SDC Stylesheets are output in the wrong order (relating to normal libraries) Active from the list. After some investigation, we notice this one is not specific about SDC.

🐛 Components without props throw error Fixed is the only code issue left inside the core/modules/sdc folder blocking 🌱 [META] Create Single Directory Components for the Olivero theme Active .

🐛 Components without props throw error Fixed is now fixed. One less blocker!

I don't think we can make 🌱 [META] Create Single Directory Components for the Olivero theme Active a stable blocker without changing Olivero's policy that prevents depending on experimental modules. My thinking is that we want to make SDC stable, and then start using it in Olivero.

Based on this I am moving it to the non-stable blocker section.

Triaging issues. I moved these (completed) items under the stable blocker section:

• 🐛 [SDC] Improve error handling during prop validation errors Fixed
• 🐛 Unhelpful error message with SDC when a optional variable is missing Closed: duplicate

Any dependency between Olivero and SDC must be optional so that a user is not obligated to enable SDC just to use Olivero or take Olivero as a base theme.

@xmacinfo all users will be using SDC when this issue lands. It will no longer be a module to be enabled, but something that Drupal allows, like support for postgres, Form API, or the render cache. You'll still be free to use it or not.

You'll still be free to use it or not.

If I build a theme based on the Olivero SDC variant, will I be able to override some or all SDC components included in Olivero once SDC is incorporated in Drupal (not a module anymore)?

Added a new stable blocker. This is a follow up that is 11.x only to remove some leftovers due to the BC dance.

📌 Remove SDC deprecated twig functions before 11.0.0 Postponed

@xmacinfo correct! Take a look at the official documentation → for the specific details.

Overriding an SDC component with another one makes sense.

But, actually, my question is more like:

Can I override the need for a SDC component. In other words, override SDC altogether.

For example, I create a new theme based on Olivero, but I want to use regular templates instead on a component. Can this be done or will I be locked in SDC?

@xmacinfo I think we should move this chat over to 🌱 [META] Create Single Directory Components for the Olivero theme Active and leave this to the stabilization discussions. Would that work for you?

Adding ✨ Mark sdc as obsolete for 11.x Active as a stable blocker.

Adding ✨ [PP-1] Remove the sdc module from core on 12.x Postponed as a non-stable-blocker.

Adding 📌 Document deprecation in drupal.org documentation pages Active as a non-stable-blocker.

📌 Move code from the experimental SDC module to core Fixed is in … does that mean this can be closed? 😄

I think the necessary follow ups after 📌 Move code from the experimental SDC module to core Fixed have all been addressed. They were all included in 📌 Remove SDC deprecated twig functions before 11.0.0 Postponed .

I am inclined to close this issue as well.

DX improvement 📌 Unhelpful PHP error with NULL type property Needs review