Skip to main content
Version: v1

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. You then catch a broken component in 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 or Warning, 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 isn't enabled gets only a lowercase [warning] No components found message, so the command exits with code 0 for that theme too.

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

ahoy lint skips SDC Devel, so run ahoy lint-sdc separately after the site is provisioned.

ahoy lint-sdc 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 scripts/provision-10-enable-dev-modules.sh provisioning script installs the module in the local, ci, dev and stage environments and skips it in every other environment, such as production. settings.sdc_devel.php adds the module to config_exclude_modules, so a config export leaves it out.

➡️ See Provision > Development modules 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 build 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. The step 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, set the value in .env, because a repository variable doesn't reach the step. On CircleCI, a project environment variable also works, because it takes precedence over .env.

Ignore 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