Commit .ddev directory to core

I think I would prefer to see this in some other form. Perhaps a composer plugin would be a nice option? If the plugin could be a dependency of core-dev then it could scaffold the .ddev files from a core repository.

If you do this, please make sure to leave the `name` out of the `config.yaml`, so it can take the name of the directory it's in.

I would say try to include only the non-default lines of the `.ddev/config.yaml` and probably nothing else.

I'm not entirely sure this is needed, as

`ddev config --auto && ddev composer create drupal/recommended-project && ddev config --update` gets everything done right away. Or just `ddev config --auto` if composer install has already happened.

There are other projects that have moved to including the .ddev; it doesn't do much harm if the `name` is left out, but it does seem like it's a relatively inflexible approach, and it ends up having to be maintained in parallel with DDEV's changes. Not that things change much, but for example, if the default `php_version` changes (as it will this fall) or the `database` defaults change (as they have for D11) then the config has to be updated, whereas DDEV itself would have handled all that.

Yeah I'm not sure of the benefit of shipping config.yaml because the auto configuration has just worked for me.

What might be useful though is shipping a docker-compose partial config for the Chrome container required to run JS tests and the related environment variables.

Lately, I have just been using ddev get ddev/ddev-selenium-standalone-chrome to run JS tests without any problem. And that, along with the problems mentioned in #6 I think this is a won't fix.

I think the flex points that DDEV is supplying to different developers with different workflows are important.

so that a contributor only has to type ddev start and start working? ddev start

For me this would replace:

ddev config --omit-containers=db --disable-settings-management
ddev start
ddev get justafish/ddev-drupal-core-dev
ddev restart

But for @quietone this replaces something different, I'm reading.

I believe that people who want to start working on drupal core have to make some decisions about what sort of work they want to do and what workflows suit that. I therefore think .ddev/config.yaml is too easy as it assumes those decisions are inconsequential. have talked a lot with @rkoller about the difference between justafish/ddev-drupal-core-dev and joachim-n/drupal-core-development-project as the both enable similar outcomes but the work area is different.

BTW I've tried to write up some of this into the canvas of the #ddev-for-core-dev Slack channel, which is a space for people to talk about these decisions and workflows.

Automated tests are (rightfully) an important part of Drupal core. After working with Laravel where testing "just works" out of the box with artisan test, I see getting tests running in Drupal as a hurdle to core development.

Just installed joachim-n/drupal-core-development-project, and there's still some configuration required that looks like it could be automated. Even after copying the phpunit-ddev.xml file to phpunit.xml, I get an error with the --list-tests option.

To make core dev easy it would cover more ground to automate the setup of underlying dev dependencies without locking people into ddev.

Laravel also has commands to create stub test files. Equivalent commands for Drush would be nice.