Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
I've been maintaining my contrib projects using https://github.com/ddev/ddev-drupal-contrib for some time now, and have just been leaving the .ddev folder uncommitted (via ./git/info/exclude).
But now that DDEV has become the recommendation for Drupal local development, I feel it is now safe to commit the .ddev folder to the project (as recommended by ddev-drupal-contrib) and then document in the README.md how to setup a local environment for contribution/maintenance.
Optional. Commit the changes in the
.ddevfolder after this plugin installs. This saves other users from having to install this integration.
Other projects where .ddev has been committed.
https://git.drupalcode.org/project/og/-/tree/2.x?ref_type=heads
https://git.drupalcode.org/project/domain_perm/-/tree/2.0.x?ref_type=heads
https://www.drupal.org/project/svg_image_field/issues/3449084
https://www.drupal.org/project/date_filter/issues/3532384
https://www.drupal.org/project/calendar/issues/3518635
https://www.drupal.org/project/label_help/issues/3449755
Proposed resolution
- Commit the
.ddev/folder and simplifiedconfig.yamlfile - Since DDEV doesn't auto-install Drush anymore, add
drush/drushto dev dependencies of the composer.json for standard cli tooling access. Note this module currently doesn't have any custom Drush commands, but it helps to have a fully functional DDEV local environment including drush, and it seems this is currently the only way. - Add CONTRIBUTING.md to document how to use DDEV Drupal Contrib and keep our dependencies up-to-date.
Issue fork date_recur-3537202
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
dpiSo long as it is kept up to date.
If it becomes neglected we should not hesitate to remove relevant parts.
For local dev also, this project will install everything it needs for linting by a `composer install && make lint` in the project directory. This should continue to work also.
I dont really operate like this with my contribs though, I typically install a contrib within the context of a site, whether ddev or not, alongside other contribs.
A relevant note: I recently rejected ddev scaffolding like this on SM, as I actively maintain that project and don't want ddev pieces. But since you are actively maintaining, I will not hold back in this project.
Comment #3
joelpittetThanks for the thoughtful response! Totally fair—if the DDEV setup ever becomes neglected, I have no problem with it being removed. I’m happy to keep it up-to-date as long as I’m actively contributing here.
Also, thanks for the note about
make lint. I hadn’t noticed that was already in place—very helpful. The DDEV setup shouldn’t interfere with that workflow at all, but I’ll add a note inCONTRIBUTING.mdto clarify how it fits alongside the DDEV tooling.Comment #4
ressaAnother approach could be to include all the commands in the CONTRIBUTING.md file, to get the optimal DDEV environment up and running for a project, since I see there are commands to run in CONTRIBUTING.md:
https://git.drupalcode.org/project/calendar/-/blob/8.x-1.x/CONTRIBUTING.md
I wonder which commands are saved by including the
.ddevfolder? If it is mainly runningddev config --project-type=drupaland installing Drush, then it seems to me a bit overkill (and in danger of versions getting outdated) to commit.ddev, and the commandsddev config [...]andddev composer require --dev drush/drushcould instead be included as well, but maybe there are a fair deal more commands, and adjustments?Comment #6
joelpittet@ressa It definitely will get out of date eventually—no argument there. I may be able to wrap something like
make lintinto addev lintcommand, but I’ll probably keep them separate for now to avoid stepping on existing workflows.The main benefit for me is having a consistent, isolated way to stand up this project for manual testing, without relying on a possibly patched version from another project or a contrib testbed with unrelated modules. I totally get the concern about long-term maintenance though, and I’m happy to revisit the setup if it becomes a burden. Though I am planning on keeping it up-to-date, so the burden is on me.
Comment #7
ressaThanks for clearing that up @joelpittet. I do get the benefits of having a consistent and predictable development environment, which you know the ins and outs of -- that's always great to have.
Also, we can only progress by experimenting, and trying new things out, and the insights gained might result in constructive feedback-worthy experiences for the DDEV Drupal Contrib project itself, which may get implemented, so that it may improve, to the benefit of all the other Drupal projects in the end.
Comment #8
joelpittet@ressa so true! I just happened to get this in today https://github.com/ddev/ddev-drupal-contrib/pull/148
Comment #9
ressaNice @joelpittet, great to see your improvements on the DDEV tools got included! And impressive how fast the Stylelint issues got sorted out and committed. The Drop is truly always moving :)
Comment #11
joelpittetMerging this in to fix the brittle tests. We can adjust the CONTRIBUTING.md later.