[timdiels1]

The Issue

This add-on assumes the conventional Drupal layout:

composer.json
web/

That is not always how DDEV Drupal projects are structured. For example, a superproject may keep the Drupal application in a subdirectory:

# .ddev/config.yaml
docroot: drupal/web
composer_root: drupal

project-root/
├── .ddev/
├── drupal/
│   ├── composer.json
│   └── web/
└── frontend/

A project may also use another docroot name, such as docroot/ or public/, or hold its custom PHP code in paths other than modules/custom and themes/custom.

When commands assume the DDEV project root is also the Composer root, or assume web/ is always the docroot, generated configuration can end up in the wrong directory, tools cannot find dependencies, and checks can silently skip project code.

Why This Matters

Supporting DDEV's configured layout means the add-on works with established repositories without requiring users to reorganise their project just to run local code-quality checks.

The add-on should consistently distinguish between:

• The DDEV project root, where .ddev/ lives.
• The Composer root, where composer.json, vendor/, package.json, and node_modules/ live.
• The Drupal docroot, where core/, modules/, themes/, and profiles/ live.

Those may be the same location in a standard installation, but DDEV explicitly supports configurations where they are not.

Expected Behaviour

• Resolve the docroot from DDEV_DOCROOT, including overrides from config.*.yaml.
• Resolve the Composer root from DDEV_COMPOSER_ROOT when available, with a safe fallback to the configured composer_root.
• Normalise a project-root docroot consistently. DDEV represents it as an empty DDEV_DOCROOT; downstream code should treat this as . rather than repeatedly falling back to web.
• Install and run Composer, PHPStan, PHPCS, ESLint, Prettier, Stylelint, and CSpell from the resolved Composer root.
• Generate PHPStan, PHPCS, and CSpell configuration using paths relative to the actual docroot.
• Scan modules/, themes/, profiles/, and sites/ broadly, rather than only */custom, while retaining exclusions for contrib, node_modules, public files, and generated DDEV settings.
• Continue to work unchanged for the standard Composer-root-plus-web/ layout.

Manual Testing Instructions

Test each layout after installing the add-on:

ddev add-on get https://github.com/UltraBob/ddev-drupal-code-quality/tarball/refs/pull/REPLACE_ME_WITH_THIS_PR_NUMBER/head
ddev restart
ddev checks

Standard layout:

docroot: web

Nested Composer root:

docroot: drupal/web
composer_root: drupal

Alternative docroot:

docroot: docroot

Project-root docroot:

docroot: .

For each layout, verify that generated configuration is created beside the correct composer.json, that commands find dependencies, and that the default lint scopes target the real Drupal code rather than an assumed web/ directory.

Automated Testing Overview

Add coverage for:

• a non-web docroot;
• a nested composer_root with a nested docroot;
• an empty DDEV docroot / project-root docroot;
• config overrides through config.*.yaml;
• custom code outside modules/custom and themes/custom;
• commands invoked without explicit paths, and with paths relative to both the DDEV project root and Composer root.

AI assistance disclosure

This issue was drafted with AI assistance and reviewed, edited, and submitted by me. I am responsible for its accuracy and for any follow-up discussion.

[timdiels1]

This has been based on what is done in #35 but we needed more for our headless Drupal setup.