Ensure that the Index entity's dependency config schema is sorted in a consistent manner

drunken monkey → made their first commit to this issue’s fork.

Thanks a lot for reporting this and already providing an MR. Looks pretty solid.

However, I don’t think it’s necessary to fix the dependency order right away, since the dependencies are basically fine. As far as I can see, the current unreliable ordering just means that there might be nonexistent changes reported for exported configs. Doesn’t seem worth it to report a nonexistent change in order to fix that. Seems to me like it would be fine to just have this fixed and reliable starting from the next time the user actually modifies the search index.
In case you disagree, please explain how fixing the order right away would or could be beneficial for users.

I just thought it made more sense to follow the common convention of having the configuration updated as part of the module update as necessary just like core did with the system_post_update_sort_all_config() hook 📌 Config export key order is not predictable, use config schema to order keys for maps Fixed , since that's one of the main reasons the ConfigEntityUpdater exists.

This ensures the config changes are a lot more predictable and consistent if it's done once as part of the module update, so subsequent config exports will only include things the user actually changed in the index.

the current unreliable ordering just means that there might be nonexistent changes reported for exported configs.

I think a change in the dependency order is an existent change (just like a change in config key orders according to the schema would be).

The update hook was useful for my use case because one of my distributions has multiple search index entities included and their dependencies needed to be automatically reordered in order to match what they should be on a clean install, otherwise they'd show up in my config diffs as a missing distribution change.

Either way, I don't have that strong a stance on it either way if you feel it's detrimental to the DX, and can reapply the post update hook myself, but I personally find it easier if such config changes are automatically documented for the developer via the update hook, so they're aware and can choose what to do with it after the database update (keep, or ignore it)

ConfigEntityUpdater currently leads to settings such as "processor_settings" to be reordered by weight rather than alphabetically as per the schema.

This is because ConfigEntityUpdater flags the entity has having trustedData(), meaning that it should no longer do any side effects such as removing/adding processors.

I added the explicit sorts as a fallback in case it's decided that the module should still attempt those kind of configuration changes.

Makes sense, agreed. I just fixed one comment and then merged.
Thanks again!