Skip to main content
Version: v2

SDC Devel - Single Directory Components validation

The SDC Devel project page describes the module as follows:

Provides development aids to Single-Directory Components developers.

SDC Devel validates the component YAML files of Single Directory Components (SDC) and statically checks their Twig templates for errors and best practices. It reports problems such as a template variable that the component definition doesn't declare, or a filter applied to the wrong type of value. A broken component then fails the check before it renders wrong on a page.

Vortex requires the module in composer.json and uses it to validate the components of the custom theme. The theme scaffold includes a sample component in components/button.

This page is for developers who build components in the custom theme. It shows how to validate them from the command line and how the CI pipeline validates them on every build.

➡️ See Single Directory Components in the theme scaffold

Usage​

Validation runs through Drush against a provisioned site, so build the stack and provision the site first.

To validate the components of the custom theme, run 1 of the following commands:

ahoy lint-sdc

ahoy lint-sdc runs drush sdc-devel:validate for the theme named in the DRUPAL_THEME variable. The Drush command lists the problems it finds in a table, and the Ahoy command prints that output. When the output contains Critical, Error(s), or Warning(s), the Ahoy command also prints SDC validation reported problems. and exits with code 1.

The match is case-sensitive, and the command exits with code 0 for any other output. A theme that has no components, or that isn't enabled, gets only a lowercase [warning] No components found message, so the command exits with code 0 for it too.

Confirm that the components passed: Drush prints No components errors found for, followed by the theme's machine name. Look for that line rather than the exit code, which is also 0 when nothing was validated.

ahoy lint doesn't include ahoy lint-sdc; run it separately after the site is provisioned.

ahoy lint-sdc doesn't take a component ID: it ignores any arguments and validates the whole theme. To validate a single component, run the Drush command with the component's ID as the second argument:

ahoy drush sdc-devel:validate your_site_theme your_site_theme:button

A component's ID is the theme's machine name, a colon, and the name of the component's *.component.yml file without that suffix. For example, components/button/button.component.yml in the theme gives your_site_theme:button.

The module also provides a Components status report page in the site UI at /admin/reports/ui-components.

Configuration​

SDC Devel has no configuration file of its own.

The EnableDevelopmentModulesDeployStep deploy step in the ys_base module installs SDC Devel in every environment except production. settings.sdc_devel.php keeps it out of the exported configuration, so enabling it never shows up in a config export.

➡️ See Provision > Running custom scripts and Modules > SDC Devel

The lint-sdc command and the continuous integration step ship only when a custom theme and the SDC Devel module are selected during installation.

Continuous integration​

SDC Devel runs in the test job of the continuous integration pipeline, after the site is provisioned, on the first container only (see Test parallelism). The step fails the build when validation reports problems, and exits without validating when VORTEX_FRONTEND_BUILD_SKIP is set to 1. The step reads that variable from the environment that the job loads from .env. On GitHub Actions, a repository variable doesn't reach the step, so set the value in .env. On CircleCI, a project environment variable also works, because it takes precedence over .env.

Ignoring failures​

To let the build pass anyway, set VORTEX_CI_SDC_DEVEL_IGNORE_FAILURE to 1, as a repository variable on GitHub Actions or a project environment variable on CircleCI. SDC Devel still runs and prints its report in the job log, so you can see what you're letting through.

➡️ See Continuous integration > Ignore tool failures