Enabled local development env with DDEV

Thanks a lot for suggesting this improvement!
I must admit I’m not too familiar with DDEV so am a bit overwhelmed by this MR.
Could you please tell me some examples of other modules that have already done this? Do you have links to some issues that discuss this change?
Adding a whole new folder with 19 files seems like a pretty big change. What exactly is the advantage of doing this, seems like most of this is auto-generated? (In fact, could you please tell me which parts are not auto-generated? Is it just the first few lines of .ddev/config.yaml? If so, wouldn’t DDEV be able to generate the rest anyways, without us including it in the repository?)
Also, what exactly is the use case for which this is needed? Is this for including Search API in any website project, or just for testing Search API on its own in a test environment?
Finally, why did you choose MariaDB and specifcally version 10.11? Isn’t hard-coding that in our module repo a problem?

A Slack conversation started here: https://drupal.slack.com/archives/C3E9QDZ5M/p1745499507960159
Where I have also shared this link that lists all contribs hosted on Drupal Git with DDEV enabled: https://git.drupalcode.org/search?group_id=2&scope=blobs&search=filename...

Yes, most of this is auto-genarated code at the moment of DDEV and necessary DDEV addons (if any is necessary) configured for the project. The benefit of committing these files that they drastically speed up contribution to projects, because whoever has DDEV installed - the official Drupal development tool for Drupal and contribs as far as I know - could just git clone the project and run ddev start and start contributing. They do not need to follow manual steps and ensure the right set of dependencies are installed, because the committed "last known good" configuration is in the version controlling system already.

Ignoring these configs from artifacts of course is a must, because when you install a module from an artifact you most likely do not need the bundled DDEV config.

OK, thanks for the detailed explanation!
I will still leave this open to be reviewed by others since I know too little about it to confidently say whether this makes sense or not. But I see no problems so far.

I haven't used this yet either, but I think that committing this as is is a good idea now that drupal has standardized on ddev.

I use ddev every day. But I must admit that I don’t like that approach. Way too much stuff to store inside a module.

Hi, DDEV maintainer here. I don't usually encourage committing .ddev in contexts like this.

And here, it seems especially inappropriate, with included add-ons at specific versions, etc.

IMO it would be much better to just explain to people in the README how to configure DDEV for local development.

We encourage committing the .ddev to projects, for a team to standardize and maintain, but this is a completely different situation

That message from @rfay seems like a good reason to won't fix this issue.

I'm glad and honored that Randy joined the conversation! I'm planning to write a comprehensive response to his comment, but I need at least one more day to put it together. If there's time to wait before closing this discussion, I would really appreciate it.

Changing status, because it's clear there's no consensus at this time.

I thought about this again. I agree, that it might easy contributing, especially in cases where a third party backend like Solr or elastic is required.
But instead of putting a complete ddev config inside each module, a single config file should be sufficient. Comparable to gitlab CI, phpunit, github actions, etc.
So a single yaml file that contains essential ddev settings and dependencies. in that case, for sure another component or module is required that creates the complete ddev environment from it.

The scope of this conversation has widened in unexpected ways. Since many projects already have .ddev folders committed as mentioned in previous discussions, I assumed the main debate about whether this is a good practice had already been settled. However, I recognize there are valid concerns about different use cases and project types.

I'm partially surprised by the pushback. DDEV has become the de-facto development environment for Drupal projects and provides the essentials for reproducible development and QA environments. While it doesn't offer the same level of
reproducibility as Nix, it represents a significant step forward. The ddev-drupal-contrib addon is officially maintained by DDEV and provides the same flexibility and reliability for contrib development. It not only accelerates initial
project involvement but also ensures that every development environment shares identical dependency versions and tools for contribution.

I understand there are different perspectives on this, however I believe contrib modules can also benefit from standardized development environments that facilitate consistent testing and contribution workflows.

In an ideal world, Drupal.org would provide a single command to spin up DDEV development environments for contrib modules. The majority of contrib modules don't require special dependencies or third-party software for development or
testing, so the same script could cover approximately 95% of contrib projects. However, even if such a script existed - and I hope this comment catalyzes its creation - some projects would still need custom config.yaml files,
Docker files, or other overrides like version pinning committed to their repository. Therefore, the .ddev folder wouldn't disappear completely.

The idea about a single YAML file also makes sense, but I believe that would contradict DDEV's composable extensions concept, which is genuinely powerful. You can find extensions for various needs without maintaining your own custom solutions.

Having a .ddev folder also proves valuable when an extension's latest release needs tweaking or bugfixing. For example, changes from pending PRs could be committed to a module's .ddev folder today, and the
extension can be updated after the PR gets merged. This approach also enables immediate onboarding for new contributors who can run ddev start and begin contributing within minutes, rather than spending time configuring their local environment.

Perhaps we could explore a hybrid approach where the .ddev folder contains only the minimal, project-specific configuration needed, while leveraging the ddev-drupal-contrib addon for common functionality. This would reduce maintenance overhead while preserving the benefits of reproducible environments.

Ideally, in the future, boilerplate code for providing local development environments will be reduced. However, I still see significant benefits in leveraging DDEV's composability through extensions and maintaining project-specific
.ddev folders with explicit dependencies and their versions. Yes, this approach introduces minor maintenance overhead for contrib maintainers, but the benefits should outweigh the consequences.

Additionally, perhaps in the future GitLab CI could also leverage DDEV to run automated QA for modules, which would lead to truly reproducible builds across development and testing environments.

I added ddev and ddev-drupal-contrib to Svg Image Field contrib module and to Rivet contrib theme, but ddev-drupal-contrib advocates for also committing the custom ddev commands it provides, it does become burdensome to keep things updated as the drop keeps moving (between ddev updates, drupal updates, ddev-drupal-contrib updates).

instead of putting a complete ddev config inside each module, a single config file should be sufficient.

Ideally, in the future, boilerplate code for providing local development environments will be reduced.

Strong 1+. This seems like the ideal goal to shoot for. For example, it would be fantastic if ddev addons (like ddev-drupal-contrib) could be added to a single .ddev/config.contrib.yml file and not have to commit all those custom commands. Users could run ddev config for their environment, and ddev pulls in the contrib file. Configuration overrides & customizations would go in .ddev/config.local.yml. Then, if the contrib module or theme itself needs custom DDEV commands, docker settings(?), or other things it could either commit them directly to the module's .ddev folder or create a separate ddev-addon-template, and add a dependency for their own ddev addon maintained in a separate codebase.

I don't see why individual modules should add ddev configurations, why not have a single ddev environment for a specific core branch and then clone the projects into there?

Why not use a single DDEV environment for a core branch and clone contrib projects into it?

Two main reasons:

• DDEV environments are cheap to spin up. It’s better to isolate contrib modules in their own environments to avoid conflicts and ensure clean, reproducible setups. Sharing a single site across unrelated modules can create unnecessary complexity around config, database, and dependency management.
• Composer isn’t great at working from local composer.json files across multiple contrib modules. It typically tries to fetch packages from the web, making it hard to test local changes to a module’s dependencies. By contrast, ddev-drupal-contrib builds directly from a module’s local composer.json, including require-dev dependencies for optional integrations.

This approach avoids local dependency tree hell and ensures all contributors run the same clean, isolated, and predictable environment.

Seems like mxr576 accidentally set this to RTBC in #15, so setting back to NW. I’m leaning towards “Closed (won’t fix)”, though – the ddev lead developer saying it’s a bad idea sounds hard to beat.
If you can come up with a single file that you’d say is almost as useful as your current proposal (as mkalkbrenner suggests in #14), and if it’s easy enough to maintain I might still consider it, but would still need stronger support than now.

ensures all contributors run the same clean, isolated, and predictable environment.

I don’t plan on using ddev for my local contrib dev environment, so that’s actually more a con than a pro in my books.