>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3559151. --> Reported by: [star-szr](https://www.drupal.org/user/1167326) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Currently, development for config_enforce_devel happens in a separate project: <a href="https://www.drupal.org/project/config_enforce_devel">https://www.drupal.org/project/config_enforce_devel</a></p> <p>This was originally done as a security measure: config_enforce should be in your composer <code>require</code> section, and config_enforce_devel should only be in your <code>require-dev</code> section. The upshot of this is that in production, the tool that is used to change enforcement settings isn't even available (i.e. the code isn't sitting there waiting to be enabled/installed, in contrast with something like Views UI). Note: In addition, config_devel is a dependency of config_enforce_devel, and may be best to keep out of production files.</p> <p>As a consequence of these two being separate projects, development on these two projects has multiple points of unnecessary overhead due to the need to manage two separate projects. There are code paths from Config Enforce Devel that depend on code from Config Enforce, and keeping them in sync is not a simple task and developer experience is not very smooth.</p> <p>On a more practical level, there are some other consequences:</p> <ul> <li>Issue management: We often need to create essentially duplicate issues (and MRs, etc.) across both projects</li> <li>User friendliness: Users may be confused as to where to report bugs/request features/etc.</li> </ul> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>We still want to maintain two separate projects on drupal.org, two sets of releases, and the require/require-dev structure outlined above.</p> <h4>Code structure changes</h4> <p>Do a subtree merge to pull config_enforce_devel's codebase with history (excluding .local-dev, .ddev, and some other directories/files) into <code>./.config_enforce_devel</code> in this repository. In our testing, including a dot-prefixed module into the codebase makes that submodule "invisible" to Drush and the Drupal UI and not able to be installed. This way the edge case users that are doing something unconventional such as directly cloning config_enforce or configuring composer to clone all dependencies (prefer-source option), would not end up with config_enforce_devel ready to install on their production environment.</p> <p>Regardless of where we place config_enforce_devel's inside of config_enforce, we will update .gitattributes to exclude all config_enforce_devel files from packaging, so that when pulling in config_enforce via composer, or even a zip or tarball, config_enforce_devel will not be included. One edge case is that composer can be configured to clone all dependencies (prefer-source option), which would end up including config_enforce_devel's code.</p> <p>We will pull over the local-dev and DDEV setup from config_enforce_devel and adapt it to work with config_enforce and the revised file structure that we come up with. config_enforce_devel can likely be brought in as a path repository in our local-dev composer file.</p> <p>We will also need to figure out a releasing/packaging strategy so that we push releases to config_enforce_devel, in terms of git <code>git subtree push --prefix .config_enforce_devel</code> seems like it would be part of it. On a related note but likely out of scope here, we may want to be more precise about our composer requirements in between the two projects, or at least more aware of potential incompatibilities between the two codebases. It seems to me the simplest thing would be to make config_enforce_devel's composer.json depend on the same version as "self" at all times.</p> <p>Move any relevant issues from Config Enforce Devel to Config Enforce, possibly under a new Component called Config Enforce Devel. Remaining issues can be closed, and the Config Enforce Devel issue queue can be closed. We can then link from the Config Enforce Devel project sidebar to the Config Enforce issue queue.</p> <p>We also considered that currently we could have a maintainer that only works on Config Enforce Devel. Going forward, such a maintainer would not have direct VCS write access, and their MRs would be reviewed/merged by full maintainers, in a model somewhat similar to Drupal core and its subsystem maintainers.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>Experiment with placement of config_enforce_devel inside config_enforce, to see if we can have Drupal's extension system ignore config_enforce_devel code, even if it's present (which might be the case if a user cloned the module in, or used composer with prefer-source).</p>