Skip to main content

Contributing

Eddy welcomes bug reports, fixes and changes to these docs. Report bugs and suggest changes in the issue queue, and send code and docs changes as pull requests against main.

This section is for people who work on the Eddy template itself. To work on an extension created from Eddy, see Development.

What lives where​

The project root holds a working Drupal module, the demo extension. The rest of the repository turns it into a reusable template:

  • install.php - the one-off interactive installer that renames, rewrites and prunes the template files for a new project. In an empty directory, it downloads the template first. It deletes itself at the end, unless you answer no to Remove this script.
  • scripts/eddy-tooling - installs the drevops/eddy-tooling package into vendor/. The package's commands build, provision and deploy the extension. Generated projects get the package from Packagist. This repository installs .eddy/tooling as a symlink, so an edit there applies to the next command without a release.
  • .eddy/ - everything used to develop and test the scaffold itself, including the source of the tooling package. install.php removes it from generated projects.
  • .claude/skills/ - the Claude Code skills for maintaining the scaffold, such as create-eddy-tooling-release-notes. install.php removes each skill that its eddy_skills() function lists from generated projects, so add a new skill to that list. InstallHelpersTest fails until the list matches the skills that git tracks in .claude/skills/.
  • .github/workflows/eddy-*.yml - the workflows that test Eddy and publish the tooling and these docs. install.php deletes every .github/workflows/eddy-*.yml from generated projects, so give the prefix and the .yml extension only to a workflow that stays in Eddy.

The .eddy/ directory holds these parts:

  • .eddy/assets/ - the animated demos that these docs and the README embed, the generator that records them and the social preview card.
  • .eddy/docs/ - the source of these docs (see Documentation).
  • .eddy/tests/ - the PHPUnit suite that validates the scaffold (see Scaffold tests).
  • .eddy/tooling/ - the source of the drevops/eddy-tooling package. eddy-publish-tooling.yml mirrors it to that read-only repository, which Packagist serves (see Tooling releases).
  • .eddy/skills/ - the update-consumer-eddy skill that generated projects fetch to update themselves.
  • .eddy/CLAUDE.md - the maintenance reference.

README.md, CONTRIBUTING.md, MIGRATION.md, SECURITY.md, LICENSE.txt and logo.svg belong to Eddy itself. A generated project gets its own README.md and CONTRIBUTING.md, rendered from README.dist.md and CONTRIBUTING.dist.md, so keep consumer-facing notes in those templates.

Build and test the demo extension​

The demo extension builds and tests like a generated project, so the Development commands apply here too. The 1 difference is the tooling package, which comes from .eddy/tooling.

To build, lint and test the demo extension, run:

ahoy build   # or: make build
ahoy lint    # or: make lint
ahoy test    # or: make test

The PHPUnit suite in .eddy/tests/ that validates the scaffold runs separately, as Scaffold tests shows.

The maintenance reference​

.eddy/CLAUDE.md is the full maintenance reference, written for AI agents and humans alike. It also covers these topics:

  • The marker blocks that install.php prunes the template with, and the rules a block must follow
  • The text that install.php renders from the answers
  • The steps for adding a Drupal major or a development tool
  • How install.php picks the workflow branches, the GitHub repository and the template version
  • The conventions for writing the scaffold tests
  • How to regenerate the animated demos and the social preview card

In this section​