Overriding already overridden libraries-override requires knowledge of previous libraries-overrides

For now you need to use the full path. See test_theme.info.yml for examples. http://cgit.drupalcode.org/drupal/tree/core/modules/system/tests/themes/...

#3: In other words, after stable overrides the system/base library, the key is replaced with a drupal-root-relative path to the NEW stable css file, this is the key you should use in overriding.
In Stable we have

  system/base:
    css:
      component:
        ...
        css/components/autocomplete-loading.module.css: css/system/components/autocomplete-loading.module.css
        ...

So your version should be:

libraries-override:
  system/base:
    css:
      component:
        /core/themes/stable/css/system/components/autocomplete-loading.module.css: false  

For now, the path has to be hard-coded until dynamic path names like '@stable/css/...' are implemented.

OTOH, using streamwrappers is more elegant than using dynamic @ theme names. #1308152: Add stream wrappers to access extension files

Don't you think a stream wrapper is not a bit overkill for referencing a theme?

Perhaps. But consider that there is more than just one use case for streamwrappers and this happens to be one of the stronger ones.

And in many cases you would not have to use the stream wrapper but it does seem like a compelling option to have available! Thanks for that @almaudoh.

Not working for me:

name: Mercante
type: theme
description: Tema para o site Mercante.co
core: 8.x
stylesheets-remove:
  - @stable/css/system/components/ajax-progress.module.css
libraries-override:
  system/base:
    css:
      component:
        css/components/ajax-progress.module.css: false
        /core/themes/stable/css/system/components/ajax-progress.module.css: false
        core/themes/stable/css/system/components/ajax-progress.module.css: false

@rbaprado I tested that .info.yml file, worked fine for me. Here is a more minimal one that also worked for me. I tested with 8.0.x (commit dbf84c49d57156be0a3527f2808caa6dc44aa168) and Standard profile.

name: Mercante
type: theme
description: Tema para o site Mercante.co
core: 8.x
libraries-override:
  system/base:
    css:
      component:
        /core/themes/stable/css/system/components/ajax-progress.module.css: false

Edit: And it should probably be said, make sure you clear caches :)

Discussed this with @effulgentsia, @alexpott, @xjm, @joelpittet, @lauriii, @catch and we agreed that this is a bug but is not major.

For now we should create a follow-up issue to document the different ways you can use libraries-override (including the full path way). Then we would update those docs based on the solution that we come up with here.

Oops, tagging for the followup docs issue to be created.

I cannot get this working for the life of me.

Everyone says use stable at the very least for a base theme, so I'm doing that, but that is making this more complex as far as knowing what keys I should be overriding here. And all I want to do here is:

1 - Override one of the 3 CSS files.
2 - Remove the other two.

I have tried everything I can think of, but neither of these work:

libraries-override:
  contextual/drupal.contextual-links:
    css:
      component:
        /core/modules/contextual/css/contextual.module.css: false
      theme:
        /core/modules/contextual/css/contextual.theme.css: css/overrides/contextual.theme.css
        /core/modules/contextual/css/contextual.icons.theme.css: false

libraries-override:
  stable/drupal.contextual-links:
    css:
      component:
        /core/themes/stable/css/contextual/contextual.module.css: false
      theme:
        /core/themes/stable/css/contextual/contextual.theme.css: css/overrides/contextual.theme.css
        /core/themes/stable/css/contextual/contextual.icons.theme.css: false

It tried all types of variations with the paths, including the full path, not including it, including the preceding slash, not including it. I tried explicitly setting base theme: stable in case there was some weirdness around that. Nothing.

No matter what, I still get all 3 files from Stable as if I did nothing.

I'm compelled to argue for this being a major. I understand that the bug itself of overriding a library that has already been overridden might not be considered major, but the problem we have is that Stable overrides practically everything. The end result is most people are starting from a point where these are already overridden. That is tantamount to the api being broken.

@Jacine, looking at what Cottser wrote in #11, you have to leave the original library name, but use the full path of the new CSS fie. So contextual lib, with stable css file path.

Ah, Drupal TX is brutal.

What David suggested is working (thank you!).

To help others that run into this, this is what worked:

libraries-override:
  contextual/drupal.contextual-links:
    css:
      component:
        /core/themes/stable/css/contextual/contextual.module.css: false
      theme:
        /core/themes/stable/css/contextual/contextual.theme.css: css/overrides/contextual.theme.css
        /core/themes/stable/css/contextual/contextual.icons.theme.css: false

And this is the logic:

1. Use the original module (or core) namespace for library name.
2. Use the path of the most recent override (in my case Stable) as the key
3. Use the full path to the file

Why would using a stream wrapper be more elegant? Have those been used anywhere else in a yaml file? It seems weird to use it there, versus using the @ token which we use for other things. Twig extends, for example.

Why would using a stream wrapper be more elegant?

I guess I'm seeing this from a programmer's standpoint. Streamwrappers are already part of php and so we wouldn't need to write additional code to parse the @themename tokens.

I'll look into a fix for this bug.

Have those been used anywhere else in a yaml file?

Not yet, because we don't have the streamwrappers in core yet. But IMHO, using a string like theme://stable/css/contextual/contextual.module.css: false looks just as nice as using @stable/css/contextual/contextual.module.css: false. The difference being that the streamwrappers approach would be usable in any context (not just in yaml files).

I ran into that issue and noticed that even if I provide the full path to the css file (in stable) like mentioned in #18, the file provided by stable does not get removed. I end up having both files linked/imported the one that stable provides and the one that my theme provides as an override.

To make this work I had to put both the library_override AND a stylesheet_remove in the info.yml file to get the desired behaviour of replacing the css file.

@pixelmord can you please provide the YAML you used? Otherwise we may not be able to help or reproduce.

@Cottser regarding #24:

I use core 8.2.4

OK so the issue occurs with this yml ( The theme is currently sub-theme of Seven, which itself is a sub-theme of Stable):

name: Thunder Admin
type: theme
core: 8.x
base theme: seven

stylesheets-remove:
 - '@thunder_article/css/article-form.css'

libraries-override:
  seven/install-page:
    css:
      theme:
        css/theme/install-page.css: css/install-page.css
  node/drupal.node:
    css:
      layout:
        /core/themes/stable/css/node/node.module.css: css/content-form-layout.css

libraries-extend:
  tour/tour-styling:
    - thunder_admin/tour-styling
  paragraphs/drupal.paragraphs.admin:
    - thunder_admin/paragraphs.admin

libraries:
  - thunder_admin/global-styling

regions:
  header: 'Header'
  pre_content: 'Pre-content'
  breadcrumb: Breadcrumb
  highlighted: Highlighted
  help: Help
  content: Content
  page_top: 'Page top'
  page_bottom: 'Page bottom'
  sidebar_first: 'First sidebar'
regions_hidden:
  - sidebar_first

If I configure like above shown, I still have both stylesheets linked:

If I add the stylesheet that I wanted to override to te stylesheets_remove array, everything works as intended:

stylesheets-remove:
 - '@stable/css/node/node.module.css'
 - '@thunder_article/css/article-form.css'

To be clear, you did a cache rebuild and all that fun stuff?

Sure I cleared the cache.
I also tried that override again with another css file that I specifically created for testing, so I can be sure that the file shown in the above image was not attached someplace else. Same issue, after specifying the override in the info.yml file I get both files attached the one from stable and the test.css.

Just now I checked and tried to just remove the file by setting it to false, that did not work either, the node.module.css is still linked.

That is what I specified for that test:

libraries-override:
  seven/install-page:
    css:
      theme:
        css/theme/install-page.css: css/install-page.css
  node/drupal.node:
    css:
      layout:
        /core/themes/stable/css/node/node.module.css: false

It might have to do with the double inheritance of: Stable > Seven > Thunder Admin

I will fire up my debugger and see what I can find out..

It shouldn't because Seven uses Classy, not Stable directly. Stable > Classy > Seven. So any theme using Classy would have the same problem. That would be easy to test.

Yeah @David found that out as well.

And I did some step through debugging and found out that the methods in Drupal\Core\Asset\LibraryDiscoveryParser work totally fine!

The only thing that does not work totally fine is my brain, because after some serious thinking what else could be a reason for this happening is that stable overrides TWO libraries that attach the file and my theme just did override one of those libraries, because I just did not think of that!!
What makes that worse is the fact that for the node form both those libraries are required for some reason.

So the following YML works and successfully removes the file:

libraries-override:
  seven/install-page:
    css:
      theme:
        css/theme/install-page.css: css/install-page.css
  node/drupal.node:
    css:
      layout:
        /core/themes/stable/css/node/node.module.css: false
  node/form:
    css:
      layout:
        /core/themes/stable/css/node/node.module.css: false

So no additional bug here other than what was originally reported, sorry.
However it might be interesting to find out why stable/core-node-module has two libraries that require the same css file and both get attached to the node form but that is an issue for another day...

Let me work on this over the weekend. Seeing as streamwrappers are not remotely on the horizon, let's see if we can make @theme token work.

We start with a test that should fail...

More strict YAML parser in testbots. Still expecting 1 test fail only.

Embarrassing when fail patches refuse to fail :(. Seems like the @ token is causing problems with the PECL Yaml parser on the testbot. I'm using Symfony Yaml parser on my local machine, so I'll remove the @ token just to confirm the patch fails.

A more careful look at the test result shows that the test actually fails, it's just that DrupalCI does not report it. https://dispatcher.drupalci.org/job/default/281509/consoleFull

So here is a full patch with the fix.

This patch does the following:
1. Allows the use of the original overridden asset path when overriding (no matter how many parent themes have already overridden already). So for the example in #4, the override can now be written as below and will work irrespective of whether base themes have overridden them already or not.

libraries-override:
  system/base:
    css:
      component:
        css/components/autocomplete-loading.module.css: false

2. In order to maintain BC with the current behavior (which isn't very themer-friendly), it will also work if the previous overriding path is used. It will also work if using the @theme token to represent the previous overriding theme path. This approach is not necessary anymore and is not recommended.

3. If a base theme had removed an asset using path/to/original/asset.css: false, the sub-theme can reinstate it or still override that with path/to/original/asset.css: path/to/new/asset.css. This is currently not possible in HEAD, (except you use library-extends).

The entry on the left-hand side of the : is always relative to the original library location while the one on the right-hand side is always relative to the sub-theme's location. (Well that might be another WTF, but how to fix that).

So if I'm reading #1 right comment #35, the patch solves the original bug? Why do we need the dynamic path token?

Also...almaudoh to the rescue!

Why do we need the dynamic path token?

We actually don't need that anymore, so I can remove it in the next patch.

What do you think about maintaining the current behavior? Should that be removed now or deprecated to remove later? I looks like a lot of .info.yml files have already been written based on that behavior.

Also...almaudoh to the rescue!

Always happy to contribute when I can :)

I think we'll need to leave the existing behavior for backwards compatibility. A lot of people are already doing it as a work around, so we don't want to break their themes.

Ok. I have removed the dynamic path tokens and retained the existing behavior for BC.

The path doesn't have to do with where the library is located. The path is defined by the original library and is internal to the theme or module where it came from. That path is always the same.

If you want to override the system/base library, you always use "css/components/autocomplete-loading.module.css", no matter where your theme is. This path comes from the system module, not your theme.

I guess #4 is the root cause of my confusion...

#4 was just a work-around for the bug. After this patch, you no longer need to use that approach. Just what @davidhernandez says in #42 will work.

But "stylesheets-remove" will not work without the @theme_name.

The @theme_name token for "stylesheets-remove" is not affected by this patch and still works as before. Also, I believe "stylesheets-remove" was deprecated in D8 for "libraries-override" and "libraries-extend". So it shouldn't be used for new themes.

This patch still needs manual test and review so it can go into 8.3.0. RTBC anyone?

I've tested last patch (#40) on 8.3.x branch at bartik/seven themes and it works for me

libraries-override:
  system/base:
    css:
      component:
        css/components/autocomplete-loading.module.css: false

1. +++ b/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
   @@ -39,6 +39,26 @@ class LibraryDiscoveryParser {
   +   * @todo Remove when BC-break is allowed.
   

   This @todo should have an issue filed against it for 9.x and the issue should be linked here.

2. +++ b/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
   @@ -143,6 +163,11 @@ public function buildByExtension($extension) {
   +          // Update to the overridden source in libraries-override.
   +          if (!($source = $this->getLatestOverridePath($source, $type, $id, $extension))) {
   +            // Don't bother if the override says 'false'.
   

   The value assignment in the if is unnecessarily tricksy to read cause of the negating and additional brackets. Also the comment inside the if code by more descriptive.

   $source = $this->getLatestOverridePath($source, $type, $id, $extension);
   if (!$source) {
     // Some better comment about what a FALSE value means.
     continue;
   }
   

3. +++ b/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
   @@ -444,13 +470,16 @@ protected function setOverrideValue(array &$library, array $sub_key, array $over
       * @param string $theme_path
   ...
       * @return string
   
   @@ -460,4 +489,45 @@ protected function resolveThemeAssetPath($theme_path, $overriding_asset) {
   +   * @return string
   +   *   The full path to the effective libraries-override asset or $original_path
   +   *   if the asset is not overridden.
   

   I think this can return FALSE no?

4. +++ b/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
   @@ -460,4 +489,45 @@ protected function resolveThemeAssetPath($theme_path, $overriding_asset) {
   +   * @param string $new_path
   +   *   The Drupal-root-relative path to the overriding library asset.
   

   I think this can be FALSE - no?

5. ~As far as I can see the actual bug outlined in the issue summary is not tested - i.e setting an overridden value to false
6. The follow needs to created before commit - see #13
7. Does this change require a change record - not sure

Thanks for the review @alexpott
1. Opened #2852314: Remove BC layer for libraries-override that is already overridden. Also added link in @todo
2. Fixed
3. Fixed
4. Fixed
5. Added test coverage
6. #2852317: Document the different ways 'libraries-override' can be used (including the full path way)
7. There was already a CR from the parent issue https://www.drupal.org/node/2497313 which documented the correct way of doing it. The buggy behavior or workarounds for it were not really documented anywhere. I don't think we need a CR either.

Hope it's okay to re-RTBC this since the only real code change is #48.2 which is really minor.

Small CS indentation adjustment...

@almaudoh given the added test in #49 convention would mean that setting to needs review would be better than re-rtbcing yourself.

Reading the test made we wonder if we have test coverage of what happens is a base theme sets something to false but the sub theme has an override?

Also this is likely to miss the window for getting in to 8.3.0 (because there is only 5 minutes to go). The current patch is making changes to protected methods that we wouldn't make in a bug fix release like 8.3.1. In order to get this in to 8.3.x we'd need to rework the fix with a tighter focus on BC in mind (if possible). So moving to 8.4.x.

The issue summary could also to with an update to detail exactly what the issue is - much is implied rather than explained. Plus the proposed resolution needs fleshing out.

Updated the issue summary.

@almaudoh given the added test in #49 convention would mean that setting to needs review would be better than re-rtbcing yourself.

Sorry, forgot about the test.

In order to get this in to 8.3.x we'd need to rework the fix with a tighter focus on BC in mind (if possible)

@alexpott, what exactly do we need to do to get this in 8.3.x? I'm considering that more themes will end up having to use the workaround for the next 6months until 8.4.x?

[deleted]

The following (without the patch) doesn't work from a subthemed bootstrap theme (8.4):
Top of prog_tpm.info.yml

core: 8.x
type: theme
base theme: bootstrap

override in prog_tpm.info.yml

libraries-override:
  toolbar/toolbar:
    css:
      theme:
        /core/themes/stable/css/toolbar/toolbar.theme.css: css/prog_tpm.toolbar.theme.css

cache cleared...

Bootstrap doesn't use Stable. Unless Bootstrap overrides one, you'll be getting libraries and assets directly from core.

@davidhernandez
My bad... I was looking in an admin page!!!

I would like to override a toolbar stylesheet for my theme and my admin theme...
For the theme (not admin), I can add the libraries-override in info.yml, but for the admin theme, should I create a subtheme and add the same libraries-override in the subtheme.info.yml just for that?
If yes, how could I make it point to the same overrided css file used in my site theme or, maybe, I must duplicate it? (or is there any other more clever solution?)

I can confirm #56:
Patch #50 does not fix this bug on 8.3.2, at least for Seven sub themes.
Still got issues with these files in my subtheme of seven. I need to include these files below in my own subtheme.info.yml to make the status report page to look nice.

libraries-override:
  system/base:
    css:
      component:
        /core/themes/stable/css/system/components/system-status-counter.css: css/components/system-status-counter.css
        /core/themes/stable/css/system/components/system-status-report-counters.css: css/components/system-status-report-counters.css
        /core/themes/stable/css/system/components/system-status-report-general-info.css: css/components/system-status-report-general-info.css

And that title...

reroll

Remove "Needs Reroll" tag.

Can we have more people do further manual testing on the patch. I've not been able to replicate the issues mentioned in #56, #57 and #60.

Thanks, @vaplas. Patch #70 now needs manual testing from others...

+++ b/core/lib/Drupal/Core/Theme/ThemeInitialization.php
@@ -190,8 +190,9 @@ public function getActiveTheme(Extension $theme, array $base_themes = []) {
-    // Get libraries overrides declared by base themes.
-    foreach ($base_themes as $base) {
+    // Get libraries overrides declared by base themes. Reverse list to override
+    // from parent to child.
+    foreach (array_reverse($base_themes) as $base) {

I'm wondering about the BC implications of this change. Might something rely on the current order? That said, this is obviously the correct way to process overrides and maybe we can consider the current behaviour just very buggy and themes are likely to have had to come up with ways to address this themselves.

+++ b/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
@@ -38,6 +38,26 @@ class LibraryDiscoveryParser {
+  protected $originalLibraryPaths = [];

@@ -409,37 +437,38 @@ protected function isValidUri($string) {
+      // For BC we check if $original still refers to base-theme overrides.
+      // @todo Remove BC in Drupal 9.0.0 https://www.drupal.org/node/2852314.
+      if (isset($this->originalLibraryPaths[$original])) {
+        // Here $original actually refers to an overridden path (maybe from a
+        // base theme), so get the actual original path by which the library
+        // asset was keyed.
+        $original = $this->originalLibraryPaths[$original];
+      }

I think we should trigger a silenced deprecation here because this only happens for BC - right?

That'll mean that tests that invoke this code will need to be legacy tests and expect the deprecation message.

This patch fixes three different problems for the thunder_admin theme:

1. Overriding an asset in base theme changes the key to absolute path.

For example stable and seven both provide an override for misc/vertical-tabs.css in core/drupal.vertical-tabs. Unfortunately the override in stable changes the key for said asset to an absolute path '/core/themes/stable/css/core/vertical-tabs.css', therefore the override in seven does nothing

2. Order of library overrides is wrong.

Without patch the order in which library overrides are applied is broken. For the thunder_admin theme we had (seven > classy > stable > thunder_admin) after applying the patch it is as expected (stable > classy > seven > thunder_admin).

3. Order of assets in overriden libraries is wrong.

If you try to override assets in a library with multiple assets the order of these is not respected, overrides are simply added at the bottom. Since the order of css assets in seven/global-styling is important, it is impossible to override single assets.

I'm pretty sure the #76.1 and .2 are tested by the patch but does .3 have test coverage?

Also I think this is a major bug because without fixing it extending from other themes doing overrides is impossible.

.

.

Add deprecation warning, align tests and fix seven,
add test for #76.3.

Should be green after https://www.drupal.org/i/2973791.

Testbot wobble.

Rerolled patch for 8.7.x

Confirmed patch in #81 fixes issues with removing hidden.module.css via:

libraries-override:
  system/base:
    css:
      component:
        css/components/hidden.module.css: false

Prior to the patch I needed:

libraries-override:
  system/base:
    css:
      component:
        /core/themes/stable/css/system/components/hidden.module.css: false

@volkerk pointed out to me that this is related to #3019482: ActiveTheme::getBaseThemes() can return the wrong themes - that issue fixes the list of base themes to be correct for an active theme. Atm it is not always which makes this even harder.

I don't understand the test fails yet, so a reroll first. Maybe #3019482: ActiveTheme::getBaseThemes() can return the wrong themes may solve it.

We'll wait for #3019482: ActiveTheme::getBaseThemes() can return the wrong themes.

Looks like that other issue was close as duplicate of yet another issue which has actually been fixed now.

Re-uploading patch in #91. Let's see if it passes now.

Actual patch now...

Let me take this on again...

Re-roll first

A key component of patch #81 was missed out in subsequent re-rolls (notice the change in file size). This has been reinstated.

This latest patch works as expected. Thanks!

Here's a working example - https://git.drupalcode.org/project/encontrarlo/commit/64bbcf8

#105 did manual testing.

The patch no longer applies though — this needs a reroll!

Just a reroll

Failures in #107 are due to deprecation notices.

@sokru - It is recommended that you remove the "Needs reroll" tag after you upload the rerolled version.

Rerolling for 8.9.x.

Deleted

The patch in comment #115 broke my site with this error (Tested on Drupal 8.9.0) :

ArgumentCountError: Too few arguments to function Drupal \\ Core \\ Asset \\ LibraryDiscoveryParser :: setOverrideValue (), 4 passed in core / lib / Drupal / Core / Asset / LibraryDiscoveryParser.php on line 446 and exactly 5 expected in core / lib /Drupal/Core/Asset/LibraryDiscoveryParser.php on line 502

I changed only the the 2 call to method $this->setOverrideValue to get this working.

Patch has been recreated to reduce test errors made by my old patch.

Development should now be done against 9.1.

Here I have added reroll of patch #120 for Drupal 9.1.x.

Can someone help me... i'm trying to unset/override /core/modules/layout_builder/layouts/threecol_section/threecol_section.css

I have tried many variations of

libraries-override:
  drupal/layout-builder:
    css:
      component:
        /core/modules/layout_builder/layouts/threecol_section/threecol_section.css: false

what am i missing/doing wrong?

You are attempting to override the CSS with the incorrect library key and also the incorrect CSS group @bradallenfisher:

Try this:

libraries-override:
  layout_builder/threecol_section:
    css:
      theme:
        layouts/threecol_section/threecol_section.css: false

Also as per this thread, one only needs to use the absolute path for the CSS file if it is overridden already. This is not the case as it seems from the initial code snippet, so one can use the same path as its definition in its corresponding layout_builder.libraries.yml.

Thanks @wongjn,

I guess im just confused by the docs. The example to override css from the contextual links module

libraries-override:
  contextual/drupal.contextual-links:
    css:
      component:
        /core/themes/stable/css/contextual/contextual.module.css: false

uses a key pattern like contextual/drupal.contextual-links:.
How did/do you know that you are supposed to use the key:

layout_builder/threecol_section: ?

@bradallenfisher you have to find the original library definition. This isn't something to guess. The first part of the key is the name of the module or theme where the library resides and the second is the library name. If you look in the layout builder module's own library file you should see the libraries it declares.

@davidhernandez thanks man i have it all sorted now. :)

Patch for 9.3.x and applies on 9.2.x.

Fixing custom command failures in #132

It's been a long week....

1. Fixes deprecations in #135
2. Updates comment for BC to 10.0.0
3. Adds the key to the deprecation message to make it clear what needs updating

Some of those failures seem to indicate maybe this isn't working as intended? In any case this will fix the js.module.css failures.

Oh wow, this seems really bad. Seems like this makes the overrides in a theme an interface that technically can't ever change because it could break subthemes... Yikes.

Also yeah, the experience is frustrating :)

So there are some problems with the last patch that should be fixed with this patch.

• BC references wrong version.
• Deprecation is in the wrong format, that's been standardized now.
• Deprecation test is broken, annotations don't work anymore.
• theme info file is missing again making tests fail.
• tests use deprecated jquery.ui meaning there are additional deprecation messages and deprecation test fails after being fixed. I used vertical-tabs instead.
• addition library-overides nested key in subtheme.info caused problems with tests.
• I don't think the dictionary addition makes sense
• the ensure-order css library was in the wrong location in the subtheme file. seems to be an artifact of one of the re-rolls.

Additionally I went ahead and renamed the "legacy subtheme" to match the other legacy themes.

There should be two failures.

1. I purposely broke the deprecation test message to be updated once the change record exists.
2. It seems the order test @volkerk added in #76 is failing and something might have actually broken the logic preserving orders? Haven't figured out all the interactions and there aren't unit tests so not sure what broke.

....

I was able to override libraries previously overridden by Olivero theme like this:

mytheme2022.info.yml

libraries-override:
  olivero/global-styling: mytheme2022/global-styling
  olivero/feed: mytheme2022/feed
  olivero/navigation-secondary: mytheme2022/navigation-secondary
  olivero/progress: mytheme2022/progress
  system/base:
    css:
      component:
        /core/themes/olivero/css/components/ajax-progress.module.css: css/components/ajax-progress.module.css
        /core/themes/olivero/css/components/autocomplete-loading.module.css: css/components/autocomplete-loading.module.css

As you can see the system/base part is the previously overridden part and it required to add the full path to the Olivero's CSS file in order for the override to work.

I hope this helps others, and thank you so much for the hard work.

How do I know whether it is component, theme, layout etc.

I am trying to override autocomplete JS file set by search_api_autocomplete

libraries-override:
  search_api_autocomplete/search_api_autocomplete:
    js:
      modules/contrib/search_api_autocomplete/js/search_api_autocomplete.js: false

Thanks

maybe with /modules/contrib/search_api_autocomplete/js/search_api_autocomplete.js ? (note the "/" at the start)

Re-rolling for 9.5.x... which I know needs to be 10.x, but we need 9.5.x.

Re-rolling patch for 10.1.x

Tried to fix CCF for #149.
Please review.

Hi, patch #151 also works fine on Drupal 10. Thank you very much!