Provide single-command setup documentation

[markdorison]

Description

I would love to be able to offer folks wanting to set this up a single-command solution of some kind. I wrote the following bash script below which I am testing locally, but I am trying to determine a better way to provide something that could live in this repo. The problem is that folks won't have this repo (nor should they need it) when they are setting this up on a contrib project. 🤔

#!/bin/bash
set -ex

read -p "Enter project name: " projectname
ddev config --project-name=$projectname --project-type=drupal10 --docroot=web --create-docroot --php-version=8.1
ddev get ddev/ddev-drupal-contrib
ddev start
ddev poser
ddev symlink-project

[weitzman]

I guess we could put it in this repo (or a gist) and then folks run it with php -r. See Composer download for an example of that.

[weitzman]

Or a bash script if host side PHP is a barrier

[hussainweb]

I wonder if you can share your perspective on the script here: https://git.drupalcode.org/project/taarikh/-/commit/96c3b56ceba5159adf117cfc93c288c810dd1aa6

The other relevant file is .gitignore. In this case, I don't commit any DDEV config in the module and the idea is to recreate it when required. I have tried to explain why in the README.md (in the same commit).

[markdorison]

@hussainweb Thank you for sharing! I was leaning towards committing the DDEV configuration to make it easier for folks to get started but I think you make a good point about locking folks into the Drupal version. 🤔

[hussainweb]

I was going to as well but then I realized I needed to try my module on Drupal 9 as well. I like the script approach better and switching between two Drupal versions quickly was smooth.

[weitzman]

My preference is to check in .ddev. When folks need to switch drupal versions, they can uncomment a line in a config.local.yml, ddev restart, and ddev poser. Or skip the uncommenting do it directly with ddev config --project-type drupal9.

[jameswilson]

If you commit .ddev, what happens when the module is packaged by Drupal.org zip/tarball/packagist? and, could that cause problems when using the module on a real site you're working on locally?

Thinking on it, I guess it's not a major issue and an edge case. Eg, if you happen to be inside your module's folder inside the project and do a ddev start it won't behave in the typical way, recursing up the directory tree to find the project .ddev folder to start the project, but will try to spin up a copy of the module's ddev settings, but then I presume that would fail if you already have the project installed as maintainer or contributor, but would succeed for other devs on your project team accidentally doing the same.

[mbomb007]

I created some aliases for .bash_aliases:

# Create a new DDEV project.
alias ddev-new='ddev config --project-type=drupal10 --docroot=web --php-version=8.3 --database=mariadb:10.11'
# Add a .gitignore file for contrib development, or add lines to an existing one.
alias ddev-gitignore='[ -f ./.gitignore ] && grep -qxF ".ddev/" ./.gitignore || echo -e "# Exclude contrib development files.\n.ddev/\n.vscode/\n/vendor/\n/web/\n.editorconfig\n.gitattributes\nphpcs.xml.dist" >> ./.gitignore'
# Set up DDEV for contrib development.
alias ddev-contrib='ddev get ddev/ddev-drupal-contrib && ddev start && yes | ddev poser && ddev symlink-project && ddev-gitignore'

You could even have ddev-new run ddev-contrib at the end, and then you have "one command to rule them all".

[hanoii]

Why not doing a host command?

ddev contrib:init or the like?

[mbomb007]

I'm not sure how to add that in ~/.ddev/commands/. I found it easy enough to put it in .bash_aliases, and then I have fewer files to maintain.