Config Split: review the export before changing the baseline

Config Split changes how Drupal configuration is divided between the main sync directory and environment-specific splits. An export can therefore move or remove files from the main directory without representing the change a reviewer expected. The useful safeguard is to review the complete export, including the split directories, against the intended deployment model.

Start with the configuration boundary

Decide which configuration belongs in every environment and which items belong only in a particular environment. Document how each split is activated and which dependencies must travel with it. Keep secrets outside exported configuration.

Why an export can surprise you

Config Split filters the import and export pipeline. The active split configuration affects what is written to each destination. A deletion from the main directory can be an intended move into a split; it can also reveal that the exporting environment differs from the agreed baseline. Inspect both before accepting the diff.

Exporting with an active split is supported behavior. A blanket rule against it would hide the actual requirement: use a known configuration state and understand the partition being exported. Likewise, an import changes the active site and must be reviewed before it runs.

A reviewable workflow

1. Record the baseline, active splits and intended change.
2. Export into a clean working tree and inspect changes in every configuration directory.
3. Check that split dependencies are complete and no secret or environment-specific value entered the shared export.
4. Review the import on a representative nonproduction environment and verify the resulting behavior.
5. Commit the reviewed configuration and its deployment instructions together.

Our infrastructure work uses this discipline to make configuration changes understandable to the next operator. See the Config Split project documentation for the module's import and export model.