- Issue created by @claudiu.cristea
- π¨π¦Canada lolcode
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.
- πΊπΈUnited States rfay Palisade, CO, USA
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.
- π¬π§United Kingdom longwave UK
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.
- π³πΏNew Zealand quietone New Zealand
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. - π¦πΊAustralia sime Canberra
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.
- π¦πΊAustralia sime Canberra
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 betweenjustafish/ddev-drupal-core-dev
andjoachim-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.
- πΊπΈUnited States kentr
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 thephpunit-ddev.xml
file tophpunit.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.