dateModified-conflicts in config/project/project.yaml

[alexgit2k]

During development we often have conflicts with the dateModified-value in config/project/project.yaml, because developers set it to the currenct timestamp in their development-branches, which results in merge/rebase-conflicts.

I was wondering why the modification-time of the file is not used instead, that would save a lot of time.

[brandonkelly]

Checking file modification times isn’t performant, because directory modification dates don’t get updated when a nested file is modified. So we can’t just look at the config/project/ folder’s date modified and go with that; we’d have to recursively check each individual file.

Craft does come with a project-config/touch command though, which will update the project config’s dateModified value, even if there is a Git conflict on it currently.

[alexgit2k]

Know I understand: All files below config/project/ are parsed again, if dateModified in project.yaml changes. I thought only config/project/project.yaml will be parsed again.

I have seen that project-config/touch can correct Git-conflicts, but our development-system does not allow to merge when there are conflicts or commit yaml-files with syntax errors (when there are Git-conflicts in it). So they have to be rebased manually all the time, which is kind of annoying. Maybe you can came up with a better solution for Craft 5.

[alexgit2k]

Well, I do not even have PHP or composer installed, just Git ...

What about my other idea with the clear-caches-commands?

[brandonkelly]

None of the clear-caches commands would have any effect on incoming project config data. And if you don’t have PHP/Composer installed, I’m not sure what difference it makes. All commands will require both.

[alexgit2k]

So we could simply use the same dateModified-value forever and just execute this command during deployment.

The deployment-pipeline is executed on the production server which of course has PHP installed.

What's about using dateModified=0 and then craft project-config/apply --force at deployment?

[brandonkelly]

Even without --force, explicitly running craft project-config/apply (or craft up) on deploy will ensure all project config changes are pulled in, even if dateModified stays the same. So no need to set it to 0. Ideally you are testing merged project configs locally, or at least on a staging server, prior to deploying to production, though.

[alexgit2k]

Thanks. Of course it is tested on a staging server.
dateModified=0 looks more intentionally set, than using a real timestamp.

[alexgit2k]

Changes of dateModified in config/project/project.yaml means that any of the files in the directory config/project/could have been changed and therefore the complete configuration is parsed again.

So if a fixed dateModified-value is used, then craft project-config/apply must be executed to re-read the configuration.

[OscarBarrett]

If you are always executing project-config/apply on startup then you can fix the dateModified value like so:

use Craft;
use craft\helpers\ProjectConfig as ProjectConfigHelper;
use craft\services\ProjectConfig as ProjectConfigService;

// ...

Craft::$app->getProjectConfig()->on(
    ProjectConfigService::EVENT_AFTER_WRITE_YAML_FILES,
    function() {
        ProjectConfigHelper::touch(9999999999);
        Craft::$app->getProjectConfig()->updateParsedConfigTimes(); // Ensure the cached value of when the project config was last parsed is updated.
    }
);