#DX (Developer Experience)

Big +1, finding usages of the plugin is so much easier with this method.

+1. Been doing this in client code for a long time. I've been thinking about doing this in Layout Builder, so glad to see the concept being floated for all of core.

The DX is so much nicer rather than needing to remember or look up arbitrary strings when using/testing plugins.

I'm +1 for this, with one exception, I think entity-types should use ENTITY_TYPE_ID for DX reasons.

Dupe of ✨ Use constants for plugin IDs Active

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.

Since there's been no follow up in 3+ months going to close out. If someone still wants this feel free to re-open the ticket!

Since there's been no follow up in 3+ months going to close out. If someone still wants this feel free to re-open the ticket!

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.

Suggested API route:

experience_builder.api.info.candidate_dynamic_prop_sources:
  path: '/xb/api/v0/info/candidate_dynamic_prop_sources/{entity_data_definition}'
  methods: [GET]
  …

So: /xb/api/v0/info/candidate_dynamic_prop_sources/entity:node:article etc.

Repurposing per #3530907-7: Improve performance of /xb/api/v0/config/component by 80% → .

vinodhini.e → made their first commit to this issue’s fork.

Bot ate my credit for committing this apparently. Fixing that.

To those posting on the closed issue, you are better off filing new issues in the queue. People don't look at closed issues.

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

xjm → changed the visibility of the branch 2576533-rename-safestringinterface-to to hidden.

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.

Automatically closed - issue fixed for 2 weeks with no activity.

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

This is how hooks worked in procedural land.

We intentionally preserved that with attributes (though it's under discussion)

I would presume we'd preserve that as well if these mive to oop too.

This might not belong with the extension system, but sure exactly where it should be though.

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

Amending attribution.

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.

Since there's been no follow up going to close this one out, but if still a valid task in D11 we can always re-open

Thanks!

@pdureau want to turn #106 into it's own Meta plan?

This is now unblocked

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.