axelerant / axl-template Goto Github PK

Can we have init-ddev similar to init-lando

This probably needs composer to be available upstream before we can do this here. 2.0.0-RC1 is available and we could consider that.

@hussainweb As discussed, it would be good to present an option to set up the Behat structure. I have created a repository here https://github.com/shwetaneelsharma/behatdrupalextension which has all the correct dependencies and a working Behat structure.

Steps:

• Install composer dependencies.
• Add the behat.yml file with Mink, Drupal and DMore chrome extension. (@hussainweb Please note that we need "Google chrome or chromium running with remote debugging" for DMore chrome extension)
• Please verify whether the base_url and api_url have correct values.
• Either Initialise behat using the command vendor/behat/behat/bin/behat --init or simply import the entire structure from this repository. Please note that initialising behat creates the features and the bootstrap directory.
• Run the sample feature file using the command vendor/behat/behat/bin/behat.

If the output directory already exists and the -f option is specified, there is an attempt to delete the directory which fails:

Removing "renovate.json"...
Failed deleting files in the "test" directory
[Errno 2] No such file or directory: 'renovate.json'

This is possibly just an incorrect path error.

During the composer install process, GrumPHP installs and it asks to create a config file. This is possibly a change in some newer version as this didn't happen before. See if passing --no-interaction removes this prompt.

As this one requires lando, I think we should add that as a prerequisite.
It would be also nice to have further steps after docker run.

Right now, we don't properly detect if composer is not present. It happens only in one of the helper functions. Improve this so that there is a proper error message early enough instead of an exception.

The current default core version constraint is set to "^8.9". We should change it to "^9.0" once Drupal 9.1 is out.

I'm thinking that the --no-install option is more trouble than it's worth. More and more features of the template tool we're adding can't work if composer isn't installed. I'm thinking of dropping the support for this option. Further, since this tool is now available via Docker and whalebrew, there is an option to use composer without installing it.

How important is this option for you?

Problem statement :

I installed a Drupal 9 website using the template and while making an initial commit I faced the following issues :

Solution :

1. Add relevant comments in the files failing the phpcs on commit.

   I will be creating a PR for this.

2. At the moment I am not able figure out a way to fix the phpcpd error as it is looking for ./web/modules/custom which is not present as I don't have any custom modules on my site yet.

The current build process is very cumbersome leading me to release 2 broken tags. I have been using a PEP517 based tool to build and publish the release because it was not clear which one to use. It seems from various places that Poetry is the tool to use now. Let's get completely onboarded on that.

When running the latest HEAD release with the --lando option, there is an error:

Traceback (most recent call last):
  File "./templates/axl-templ/init-drupal", line 9, in <module>
    sys.exit(drupal.main())
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/Users/hw/work/templates/axl-templ/axltempl/drupal.py", line 130, in main
    name = name.split("/")
AttributeError: 'ComposerVersion' object has no attribute 'split'

The package zaporylie/composer-drupal-optimizations is not compatible with composer 2 (it's not even needed). Let's remove it if we detect that composer 2 is present.

Right now, commands like init-drupal accept a lot of options. It's easy to forget an option and by the time you realise it, you have to start all over again. As we think about adding new options, this problem is only going to get worse.

Should we instead prompt for options so that the user has a chance to specify each thing before the operation executes? Of course, if the user has specified it on the command line, that option won't be prompted. Let's weigh this option (pun intended):

Pros

• No need to remember multiple options
• User experience might be better as it will be interactive leading to lesser chance of typos

Cons

• Harder to use in scripts (you have to specify each option in the command line or the script would get stuck waiting for inputs)

I am leaning towards prompts because I don't see this tool used that often. Since it is only used occasionally, it's harder to remember all the options. Prompts would be helpful in those cases. Also, I don't have a use case of using this tool in a script.

Are there any scenarios I am not considering?

The directory option is confusing and prone to errors. It might be better to just ensure that the current directory is empty and if it isn't, throw an error asking the user to create a new directory and run the command there.

Alternatively, we can keep the --directory option and make it optional. If it is an empty string (or .), we check if the current directory is empty.

Neither of the above breaks the current workflow significantly. The current workflow also gives an error if the directory exists.

IMO performance must be taken into account from the beginning itself. sentry.io can help in this aspect. Although, for a longer term performance monitoring NewRelic is a better option, however it is expensive. To get started quickly, projects can use the performance feature of Sentry. Axelerant already has a subscription as well.

Motivation:

It would be great if one would be able to add any composer packages, modules while creating a Drupal codebase.

Considering the following factors:

1. Not everyone using this project wouldn't have composer binary or the right version of composer
2. or might not want to run composer install immediately after scaffolding

I propose making it optional by default which would mean changing --no-install to --install.

Currently we do not download packages for composer from Asset packagist. This is needed for bower libraries used by Acquia's Lightning profile.

Background: https://www.drupal.org/project/lightning/issues/2911640 and http://lightning.acquia.com/blog/round-your-front-end-javascript-libraries-composer

We need to add a line to composer.json as in above link and use oomphinc/composer-installers-extender to alter path of the downloaded bower libraries (this can be done if needed)

As discussed below can be alternatives.

1. Add support to optionally include asset packagist via a flag
2. Detect if lightning is one of the requirement in composer require and add it automatically.

Running this command:

env COMPOSER_MEMORY_LIMIT=-1 init-drupal --core-version "^9.0.0" --core --lando --cache redis axl/migr

composer install fails with this error:

  Problem 1
    - Conclusion: don't install drupal/console 1.9.4
    - ...
    - Conclusion: don't install symfony/http-foundation v3.4.36
    - Installation request for drupal/console ^1.9 -> satisfiable by drupal/console[1.9.1, 1.9.2, 1.9.3, 1.9.4, v1.9.0].
    - Installation request for drupal/core ^9.0.0 -> satisfiable by drupal/core[9.0.0-alpha1, 9.0.0-alpha2, 9.0.0-beta1, 9.0.0-beta2, 9.0.0-beta3, 9.0.0-rc1, 9.0.x-dev, 9.1.x-dev].
    - drupal/console v1.9.0 requires symfony/http-foundation ~2.8|~3.0 -> satisfiable by symfony/http-foundation[2.8.x-dev, 3.0.x-dev, 3.1.x-dev, 3.2.x-dev, 3.3.x-dev, 3.4.x-dev, v2.8.0, v2.8.0-BETA1, v2.8.1, ..., v3.4.9].
    - Can only install one of: symfony/http-foundation[4.4.x-dev, 2.8.x-dev].
    - ...
    - Can only install one of: symfony/http-foundation[v3.4.9, 4.4.x-dev].
    - drupal/core 9.0.x-dev requires symfony/http-foundation ^4.4.7 -> satisfiable by symfony/http-foundation[4.4.x-dev, v4.4.7, v4.4.8].
    - Conclusion: don't install symfony/http-foundation v4.4.7|install symfony/http-foundation v3.4.36|install symfony/http-foundation v3.4.37|install symfony/http-foundation v3.4.38|install symfony/http-foundation v3.4.39

The problem is drupal/console doesn't support symfony/http-foundation at ^4.4.7 which Drupal 9 needs.

It appears that drupal/core-composer-scaffold does not create the default settings.php file. It gets created on Drupal install.

OTOH, we do create a customized version of settings.php. We should allow committing it by default and remove it from the template's .gitignore.