Developers: Modul[ar]e structure

A design requirement for the project is that each suite of modules can be installed independently of the install profile and each other. Another Council Drupal site can choose to install only the Step-by-step module, or the Directories with one entry type, just Campaigns alone without any of the other modules (except for Core). They can also install a selection of them, or take the whole profile.

Preventing unnecessary dependencies while requiring more consideration architecturally can allow for modules to be upgraded and tested independently. It also allows sites to make alterations and upgrade other components without worrying about future dependency complexity.

To facilitate this there should be as few hard dependencies as possible between composer installable modules, but they can optionally extend and integrate with each other. For example: If Step-by-step is installed it does not require Services, but if it is already installed, or equally later installed, the fields will be automatically added to the Step-by-step content type so it integrates with Services.

Examples of patterns to do this in the code

Conditional content

Use \Drupal::service('config.installer')->installOptionalConfig(); in a hook_modules_installed() to explicitly import additional optional configuration.

Reacting on creation of fields

Both Services and Directories add configuration on the creation of fields. At present this is done by field name, it could be extended to field widget. This is done in the hook_ENTITY_TYPE_insert() and hook_ENTITY_TYPE_delete() where the ENTITY_TYPE is field_config. Example: localgov_directories_field_config_insert() and localgov_services_navigation_field_config_insert().