Any plans to integrate config_split_ignore in 3.x?

Hi, thanks for opening an issue and the suggestion.
Yea, that module would need to be updated to also work with the core api instead of config filter.

But I don't fully understand what it is trying to do.. it seems to be adding an ignore part to a split which seems strange. I don't know what the use case for that could be.

That said I think it is probably best in its own module because it doesn't really fit the paradigm of either of the two modules I maintain.
But if someone takes the time to explain how it is supposed to work and for what, I can give feedback on how to best integate it and maybe add some extension points to config split for it but I am sceptical for now.

Hi, I am trying to explain our use case.
We have a large multisite installation and custom and contrib modules which are used only by specific customers.
So, for example, we enable basic_cart only for some of them by enabling a split.
This is where config_split_ignore comes in.
It is used primarily to protect the settings of a split against being overridden. This couldn't be done with config_ignore because the general configuration doesn't know anything about the split.

dependencies:
  module:
    - config_split_ignore
third_party_settings:
  config_split_ignore:
    entities:
      - basic_cart.checkout
      - config_pages.type.basic_cart_settings

dependencies:
  module:
    - config_split_ignore
third_party_settings:
  config_split_ignore:
    entities:
      - 'he_dba.settings:custom_tables'
id: config_map_feuerwehr

If the settings of a split are not in the config because one cannot set them to ignore, they will be deleted at a drush cim during the deployment of a new release, as long as they wouldn't be exported with drush cex. Exporting them would, on the other hand, lead to conflicts with other site settings that differ.

Hope this explains the pain we are in a bit :-)

Thanks for the explanation.
But nothing dictates that the patterns in config ignore have to match anything. So you can totally ignore things that the main site doesn't know about. But I understand that if you have a split active maybe then there are things you want to ignore that otherwise you wouldn't.
And for that I think it is best to create a third module (and config_split_ignore sounds like an excellent candidate) and then that module can just implement hook_config_ignore_ignored_alter. Then you probably only want to ignore it for updates and deletes.. otherwise the split will not properly be imported.

Like I said I am happy to review it and give feedback, but I don't want to enlarge the scope of config_ignore for that.