on install, main icons show twice

I'll have to get my head around the asset discovery system and in particular library overrides, clearly something is not right here with the either a) unset in hook_library_info_alter() (just not the right way to go about it) or perhaps there is something suspect with the asset discovery system itself.

Toolbar Module provides two libraries that we need to alter:

toolbar/toolbar
toolbar/toolbar_menu

Stable base theme overrides the CSS in both these libraries:

toolbar/toolbar:
    css:
      component:
        css/toolbar.module.css: css/toolbar/toolbar.module.css
      theme:
        css/toolbar.theme.css: css/toolbar/toolbar.theme.css
        css/toolbar.icons.theme.css: css/toolbar/toolbar.icons.theme.css
  toolbar/toolbar.menu:
    css:
      state:
        css/toolbar.menu.css: css/toolbar/toolbar.menu.css

Toolbar Themes unsets the original Toolbar modules CSS:

function toolbar_themes_library_info_alter(&$libraries, $extension) {
  // Remove Toolbar modules CSS.
  if ($extension === 'toolbar') {
    unset($libraries['toolbar']['css']);
    unset($libraries['toolbar.menu']['css']);
  }
}

This blows away Stables library_overrides - but why not strait away on install?

Maybe I should just use a hook_css_alter() to do this, is hook_libraray_info_alter() just the wrong hook in this case - am I really just playing a trick by using an unset in hook_library_info_alter()?

I'm digging into core now.

OK, after some hours inside LibraryDiscoveryParser I do think that unsetting the type key in hook_libraray_info_alter() is little more than a fortuitous trick (with regards to library_overrides). AFAICT all this does is cause the override to fail, but at the last possible moment (in setOverrideValue() $key_exists becomes FALSE when I unset the CSS key in hook_library_info_alter()), so nothing loads at all, so to speak.

However, I still don't know why it doesn't work strait away (on install), that has me a bit stumped at this stage.

Someone who knows a lot more about this whole asset discovery system would need to look at it in more detail, but at least thats my lay interpretation of the code.

I've tested with hook_css_alter() and this works flawless (as expected) on install and all the time etc.

I want to do a bit more testing but I've run out of time today.

I asked droplet about his Toolbar Anti-flicker module which does some funky things to make the unset work on install when in hook_library_info_alter(), essentially he uses hook installed to fire an additional clear cache. #2801547: Couple of questions about install and hook_library_info_alter

So yeah, this is definitely something weird in core.

I think for our purpose hook_css_alter() is sufficient, and while being rather late and not early in asset discovery it does work and without any hacks. So we end up with this:

function toolbar_themes_css_alter(&$css) {
  // Unset CSS files we don't want or need.
  $css_to_remove = [
    'core/themes/stable/css/toolbar/toolbar.menu.css',
    'core/themes/stable/css/toolbar/toolbar.module.css',
    'core/themes/stable/css/toolbar/toolbar.theme.css',
    'core/themes/stable/css/toolbar/toolbar.icons.theme.css',
    'modules/admin_toolbar/css/admin.toolbar.css',
  ];
  foreach ($css_to_remove as $key) {
    if (array_key_exists($key, $css)) {
      unset($css[$key]);
    }
  }
}

hmmm perhaps this is too fragile on second thought, theres still a lot of what if's in play here.

Need to test more, I'll try with Anti-flicker modules ideas with the extra cache flush in hook_modules_installed(), I think its still a lot safer to blow away toolbars library assets really early, so all subsequent overrides etc fail also.

Went with the Anti-flicker modules extra cache flush in hook_modules_installed(), I think this is the safest overall method as it keeps the unset early in asset discovery and accounts for other library_overrides we don't know about.