We all learned when we were young (in Drupal experience) that contrib modules from Drupal.org go into modules/contrib and any custom code goes into modules/custom. But don't you have those custom features that you seem to re-implement for every project again and again? Or do you actually have some shared modules for multiple projects but you don't want to put them on Drupal.org for whatever reason, so you end up copying them around or using Git submodules?
Wouldn't it be nice if instead you could install custom modules via Composer but still host them in private repositories instead of on Drupal.org? Gitlab provides a way to do just that and in this session we'll go through how to set up and use the Gitlab Composer Registry.
We'll also go through some of the best practices in module development that can increase code reusability without sacrificing customizability.
Recap
There were no slides, so here are some notes of what was discussed:
- Add a
composer.json to your module repository and a .gitlab-ci.yml as documented by either including the CI template directly or adapting it to your needs to publish your module to the Gitlab Composer Registry. - Go to the package registry of the (top-level) group* of the module repository to find the Composer commands needed to enable to registry in your project. The documentation also explains how to grant Composer access to private repositories: You probably want to create a Personal Access Token for local use and a deploy token when doing a Composer build in CI for deployment.
- If you are doing a Composer build in Gitlab CI you probably want to add the value of
$COMPOSER_CACHE_DIR to the CI cache paths. - You should consider your usage of the Composer vendor in your modules (i.e.
drupal/mymodule vs mycompany/mymodule) to avoid name conflicts or be able to improve perfomance by filtering the packages of the custom repository.
* To be able to publishable in the Composer Registry, module repositories must be in a group and not be published under a Gitlab user's namespace.
