Library not picked up if located in /profiles/myprofile/libraries

I just did a quick test using the core standard profile (/core/profiles/standard/libraries/myLib) as that's what's active in a dev environment that I have handy, and the detection worked as expected. Of course that's not a real use case (custom libraries should not be added into a core profile) but it at least confirms that logic in libraries_get_libraries() is reasonably sound for the current 8.x-3.x-dev.

Can you ensure you are using the most recent 8.x-3.x-dev and that your profile (named in /profiles/myprofile/libraries/mylibrary) is in fact the active profile (as would be returned by drupal_get_profile())?

I'll go ahead and close this on account of inactivity.

The library files detection logic has also received some tweaks recently while addressing other issues, which may very well have addressed this as well (e.g. #2530042: Unit test failing and #2606420: Can't find libraries in install profiles). If the problem persists please feel free to re-open with additional details.

Steps to reproduce with https://www.drupal.org/project/mmenu (8.x-1.x-dev) and Libraries (8.x-3.x-dev):

• Create custom Drupal install profile.
• Add profile dependency: mmenu (will be located under profiles/profile_name/modules/contrib/mmenu).
• Place correct versions of mmenu main, hammer, jquery.hammer and icomoon correctly inside profiles/profile_name/libraries/mmenu
• Result: No ressources loaded from wrong path (libraries/mmenu/...)

libraries_get_path('mmenu')

returns correct path though (profiles/profile_name/libraries/mmenu).

Place libraries folder under D8 root, everything works fine due to the paths not beeing empty anmyore.

drupal_get_profile

returns correct profile.

Desired result:
Load library ressources from profile.

Is this a MMenu issue due to misconfigured mmenu.libraries.yml?

leymannx: looks like mmenu has no support for the libraries module. Have a look at #2768457: Add libraries support, there i add libraries support for the slick module

So it sounds like #3-#5 refer to an extension-specific issue and is not really related to this thread? Should we re-close this?

I guess yes. But would be nice someone else could confirm this.

The 8.x-3.x architecture has evolved quite a bit since this was opened. It's looking like library sources will be detected via specific stream wrappers. The specifics of how this will play out for profiles is still in flux, but I believe the most topical issue may now be:

#2818689: Add ability to scan multiple stream wrappers when locting library source

With more background provided in:

#2090623: Turn hardcoded library_load_files() into a more modern, flexible system

I hope those references help. Closing for housekeeping.

Yes it is reproducible issue. Facing same issue with my current profile.
Is there any solution for this? This seems valid issue and should be addressed soon.