Composer 2 puts harvesthq/chosen in wrong folder

Hi!

Did you follow the updated readme of the module?

https://git.drupalcode.org/project/chosen/blob/8.x-2.x/README.txt

The link to the original discussion: #2918901: Fix documentation for composer library setup

I agree. Do we really need a custom installer? Installing the module normally via Composer should put everything where it's supposed to go. Other modules requiring libraries don't need any of this.

As per How to install with composer external library that drupal module depends on, the above patch should be the right way to do it, but I can't find a way to test it (unless it's not working). When I apply the patch above using Composer patching, it still goes in /vendor. I'm assuming this is because the patch gets applied after the library gets installed, which doesn't help.

#2: Is there another way this should be tested?

Alternately, could we not access the library from /vendor? Does it really need to go in /web/libraries? Obviously, other modules in Drupal can access the vendor branch.

Unfortunately, composer cannot load repositories this way (for a good reason). So, the patch cannot work even if merged because composer will never read this repositories entry. The repository has to be added to the root composer.json (the main composer.json for the site). This was covered in the documentation changes introduced in #2918901: Fix documentation for composer library setup.

@cantrellnm, I know what you mean and I had submitted a PR to the package but not yet merged. Hopefully, the maintainers review it soon and merge it which will make the process easier.

I had to add the following code to the repositories in composer.json to make it work:

    {
      "type": "package",
      "package": {
        "name": "harvesthq/chosen",
        "version": "1.8.7",
        "type": "drupal-library",
        "source": {
          "url": "https://github.com/harvesthq/chosen-package.git",
          "type": "git",
          "reference": "v1.8.7"
        }
      }
    },

Mind the version is written without ^, the url is ending with .git and the reference starting with a v.

The library can be required with:

"harvesthq/chosen": "^1.8.7",

No need to execute the steps in the readme adding oomphinc/composer-installers-extender and installer-paths, seems overkill to me.

Wondering if patch is still needed? And/or if any instructions should be added to the other issue or README, either for installation or for updating.

(But overall, just wanted to check whether work is needed on this thread?)

Can confirm, that solution in #9 works, chosen appears in libraries directory.
Readme file is incorrect.

I want to point out that while the method in #9 would work, it doesn't mean that the method in README is incorrect. The method in #9 depends on adding a custom repository for the library which is not necessary (as that library is already available on Packagist). However, the package is of type library which causes it to be placed in the vendor directory. This was discussed extensively in #2918901: Fix documentation for composer library setup. There is also a PR to update the composer package type so that we could place it without using the package name in the custom installers path.

Between the two methods, I would prefer the method where we can use the package info from packagist rather than us specifying it in the repositories section. The simple reason is that updates are available without changing anything in composer.json file. Another reason is that this method involves changing very few lines compared to adding an entire repository section. Still, both methods work and someone who is well-versed with composer could choose to use the method which overrides repositories if that is what they need.

I can confirm this issue.

#3: @nagybalint, Readme is not running, because the chosen library is being installed at /vendor folder

I have tried to add the library to my composer.json like #9 and like

"chosen": {
          "type": "package",
          "package": {
              "name": "harvesthq/chosen",
              "version": "1.8.7",
              "type": "drupal-library",
              "source": {
                  "url": "https://github.com/harvesthq/chosen/archive/master.zip",
                  "type": "zip",
                  "reference": "v1.8.7"
              }
          }
      },

+
"harvesthq/chosen": "^1.8.7",

and get en error :

 [LogicException]                                                                                                                                      
  Downloader "Composer\Downloader\ZipDownloader" is a dist type downloader and can not be used to download source for package harvesthq/chosen-1.8.7.0

@SerShevchyk, that's because you're specifying zip file for source attribute. I would suggest following the README.txt file for the instructions. I'll try to provide a more detailed walkthrough this week.

for D9 with added

{
"type": "package",
"package": {
"name": "harvesthq/chosen",
"version": "1.8.7",
"type": "drupal-library",
"source": {
"url": "https://github.com/harvesthq/chosen-package.git",
"type": "git",
"reference": "v1.8.7"
}
}
}

"harvesthq/chosen": "^1.8.7",

composer show harvesthq/chosen
outputs wrong path

/vendor/harvesthq/chosen

instead of /web/libraries/chosen

I realise this is a cause for confusion for many, which is why I created a video and posted it on YouTube. In the video, I walk through the README in this module and install the module along with the JavaScript library in the correct location. I hope it is useful. Here's the link: https://youtu.be/Lo3ChjQkzok

Nice! Thank you!

Would you like to link this video on the module page?

@nagy.balint, if you like it, please do. I appreciate you asking before putting it there.

Did some reorganization on the module page.

Let me know if some text should be changed.

Okay, I am fairly new at composer - but wasn't composer used exactly to avoid stuff like this were you are downloading dependencies manually or wih extra work? If I read this issue correctly, we can download the package but it lands in "vendor" - what has to be done to use it from there and get rid of this whole problem?

Again: I am new to composer and this is just me trying to understand the underlying problem. Thank you.

@JThan, composer does a decent job at managing PHP dependencies. There are only workarounds to manage JS dependencies.

The steps to install the dependencies for this module are in the README file, or you can look at this video if you prefer: https://youtu.be/Lo3ChjQkzok

Thank you for clearing that up for me, I did not know that composer is mostly only for php-packages. DOes not make me happier right now - starting with composer is hard ;). And thanks for the video.

I did uninstall the module for now because of this, but when I later come back I will be glad to have this cleared up. Thanks.

The instructions in the README do not work for me. If I add "library" to "installer-types" composer errors out with the message

Package type "library" is not supported

#9 does work for me and is consistent with other libraries I'm including for other modules (google/charts, jackmoore/colorbox).

I just watched the video created by @hussainweb (thanks for that - lovely job!) and followed the steps from him and the readme pretty carefully but I also get

Package type "library" is not supported

I haven't tried the #9 variation but I'm curious why it isn't working.

I was also getting the message as in #25 and #26 even after following the README.

When I watched the video from #17 for the second time, I realized that the only difference is that I downloaded oomphinc/composer-installers-extender using command composer require oomphinc/composer-installers-extender which dowloaded version 2.0 while @hussainweb is using version 1.x (version 1.1 to be precise).

So I did like this:

1. Run composer remove drupal/chosen to uninstall the harvesthq/chosen from vendor directory.
2. Then edited the composer.json from "oomphinc/composer-installers-extender": "^2.0" to "oomphinc/composer-installers-extender": "^1.0" and run composer update.
3. Finally I run composer require drupal/chosen

and voila the chosen library was installed in "web/libraries" directory.

Btw I followed the README for this to work except downgrading oomphinc/composer-installers-extender. However as per
Composer Installers Extender README version 2.0 should have worked for me as I'm using php version 7.4.

Hope this will help somebody.

Thanks @DaringDV. The only difference with version 2 of oomphinc/composer-installers-extender is that it adds Composer 2 support. In terms of functionality, both versions should do the same job.

And thanks @selwynpolit for your comments. :)

Thanks @hussainweb for clarification. Now I understand that I've "composer/installers": "^1.9" in my composer.json file and that's why version 1 of oomphinc/composer-installers-extender was required.

And if I will update composer/installers to version 2 then version 2 of oomphinc/composer-installers-extender will be required.

I think most of the persons are facing issues may be due to unmatched versions of both composer/installers and oomphinc/composer-installers-extender.
Thanks once again.

I really appreciate all the work done by the contributors of this module and the support given - especially @hussainweb on this topic. No one in Drupal is responsible for Composer, most of the time it is brilliant, but it can be a pig of a thing to work with at times! Like most people, I have spent far too long trying to get Chosen installed using composer - something that should have taken no more than a minute to do!

Like most people, I wanted everything placed in the "preferred" directories - the chosen js to go in web/libraries/chosen and the drupal chosen module to go in web/modules/contrib/chosen. I followed the Readme to the letter but I kept getting the

Package type "library" is not supported

. I didn't want to frig it as in #9. I tried @DaringDV's #27 but was still getting

Package type "library" is not supported

.

The way I got it working in the end was the following do's and don'ts :-

1. Do not - as the Readme instructs - add the installer-types line to the "extras" section of composer.json - yet...!

        "installer-types": [
            "library"
        ],

If I did, I always got the error :-

Package type "library" is not supported

2. Do not run composer require drupal/chosen yet...! If you have, remove it with composer remove drupal/chosen.

3. Vital step: check your composer.json require section for "oomphinc/composer-installers-extender". If it is >= 2.0 change it to "^1.0" and then run composer update.

4. Now add the installer-types line as the Readme instructs :-

        "installer-types": [
            "library"
        ],

to the "extras" section of composer.json.

5. Run composer require drupal/chosen.

Good luck!

Ran into this today. #31 was a win for me. Thanks mautumn!

I ran into the issue (Package type "library" is not supported) and decided to go another way and install chosen library from bower-asset repository.
See for more details: https://asset-packagist.org

I already had https://asset-packagist.org in the repositories list, so all I had to do was:
composer require bower-asset/chosen

I think it can be a nice replacement for the existing instructions because many projects already have asset-packagist repository in place.
___

Here is a list of required sections in composer.json files:

"repositories": {
  "asset-packagist": {
    "type": "composer",
    "url": "https://asset-packagist.org"
},
"installer-paths": {
  "docroot/libraries/{$name}": [
    "type:drupal-library",
    "type:bower-asset",
    "type:npm-asset"
  ],
 },
"installer-types": [
  "bower-asset",
  "npm-asset"
],

From #12:

I want to point out that while the method in #9 would work, it doesn't mean that the method in README is incorrect. The method in #9 depends on adding a custom repository for the library which is not necessary (as that library is already available on Packagist). However, the package is of type library which causes it to be placed in the vendor directory. This was discussed extensively in #2918901: Fix documentation for composer library setup. There is also a PR to update the composer package type so that we could place it without using the package name in the custom installers path.

Between the two methods, I would prefer the method where we can use the package info from packagist rather than us specifying it in the repositories section. The simple reason is that updates are available without changing anything in composer.json file. Another reason is that this method involves changing very few lines compared to adding an entire repository section. Still, both methods work and someone who is well-versed with composer could choose to use the method which overrides repositories if that is what they need.

How does this sound for a plan to fix this without requiring workarounds?

1. Fork the library.
2. Fix the problem in the fork.
3. Add it to Packagist.
4. Update this module to use the fork.

I've done this for other modules, and as a concept, it seems to work fine.

It it ever does get fixed upstream, we can simply switch back to that, and then dump the fork.

@colan, that would work, yes, but it would also mean that the module will have to pay attention to the fork and revert to the original package name when (if) it gets merged. Also, chosen seems to be deprecated. So, a fork may have to pick up significant maintenance.

Thank you mautumn!.
#31 solved it for me too on Drupal 8

@hussainweb: There are two (2) possibilities: Either the library is maintained, or it isn't. If it is, problems like this get fixed and we'd need to track it (and don't need the fork). If it isn't, no changes are being made upstream anyway. So there's nothing to track, and we can do what we want in the fork as there's nothing to sync with (as the origin is dead).

Creating a fork would allow us to fix anything that's not being handled upstream, and in this case, it's only the one particular issue. If we run into other problems, then yes, we can fix those in there too, but that's outside this issue's scope. But having our own fork allows us to do that for anything else that comes up later.

but it would also mean that the module will have to pay attention to the fork and revert to the original package name when (if) it gets merged.

Yes, but that's an easy change, and it's unlikely given that it appears dead. (And to be frank, we only need to worry about this until the real issue here gets fixed in core, which is #3076171: Provide a new library to replace jQuery UI autocomplete.)

chosen seems to be deprecated. So, a fork may have to pick up significant maintenance.

Why? I don't see any need for that. In our fork, we'd only need to fix things we care about. So for this issue, we just need to merge the upstream one that we're tracking. We don't need to waste time fixing other problems we don't care about.

Thak you mautumn!!!

Ran into this today.
#31 was the solution.

Composer 1.10
Drupal Core 9.0.8

I dont know what could be wrong but i still are seeing this error that prevent drupal/chosen to be written to composer.json

 [RuntimeException]                                                                                                     
  Error: Failed to find next installable package. Remaining: drupal/chosen drupal/chosen_lib drupal/recommended-project

The oomphinc/composer-installers-extender plugin does not yet support moving the chosen library to the right place under composer 2. See https://github.com/oomphinc/composer-installers-extender/issues/26 - there is also a suggested workaround there, which is similar to the patch on this issue. I suspect that needs to be fixed; but in the meantime, is it worth changing the recommended instructions? Or at least making it explicit that it cannot yet be done with Composer 2?

All: Please review the plan I proposed in #34, and provide feedback. The current state of this issue is meant for it. It solves problems such as #40, that we'll no longer need to worry about. Thanks!

@colan thanks for providing a clear plan - I agree that the module installation instructions could be changed whilst we wait for upstream fixes. How comfortable would you be with committing to maintaining that fork whilst it's needed? e.g. updating the code, especially for security fixes, from the original library project?

Could this module just change to use npm-asset/chosen-js or bower-asset/chosen via asset-packagist.org as per comment #33? Those already work fine as they don't use the default 'library' package type, so it seems unnecessary to me to create another clone of the original package.

@colan thanks for providing a clear plan - I agree that the module installation instructions could be changed whilst we wait for upstream fixes. How comfortable would you be with committing to maintaining that fork whilst it's needed? e.g. updating the code, especially for security fixes, from the original library project?

There wouldn't be much work involved as upstream is currently unsupported.

I think it should be the job of the maintainers to maintain the fork as these things have to be kept synchronized. Having said that, however, we'd be willing to co-maintain the module. If myself or one of my colleagues were given maintainer access, we'd be happy to set up the fork, and grant access to all other maintainers. (We're already doing this kind of thing for Aegir.) Having said that, though, if the current maintainers want to do this themselves, that would be fantastic.

Could this module just change to use npm-asset/chosen-js or bower-asset/chosen via asset-packagist.org as per comment #33? Those already work fine as they don't use the default 'library' package type, so it seems unnecessary to me to create another clone of the original package.

This may be a better idea, but I don't know much about asset-packagist.org so I'll let someone else comment on this approach.

Step 3 on #31 is the one that saves me ;-)
Thanks mautomn.

Using Composer 1.10.19 & Drupal 9.1.0

I will add my 2 cents:
As there are other modules which are using this library (ex: lang_dropdown), I assume we should stick to the default installation behavior of Drupal.

Without installing this module, if I run composer require harvesthq/chosen (D 9.1) the chosen library will be installed in /libraries/jquery.chosen like any other jquery libraries (/libraries/jquery.xxxxx)

Thus, we don't need any installation instruction except composer require harvesthq/chosen as it runs out of the box.
(We can add other instructions to add an "installer-paths" for those who like to go deeper...)

...And the only thing to change would be the chosen library path in chosen.libraries.yml

Doing this way will allow other modules to re-use chosen for other purposes and will decrease the installation steps for all users.

I had to follow this comment https://github.com/oomphinc/composer-installers-extender/issues/26#issue... to get composer working on Drupal 9.1.3 using Composer 2, and update the entry on composer.json to:
"oomphinc/composer-installers-extender": "^1.1 || ^2" otherwise the Library no supported error always triggers.

If I am not mistaken, this issue which goes back a few years became an issue after chosen was added as a composer package and the instructions changed, which then caused issues as `composer-installers-extender` v2.0 (needed for composer 2) doesn't accept type library.

While I managed to also installed chosen as an npm-assets like other js libraries, as chosen still requires the library from composer I ended up with the two libraries.

In the end, taking the hint from https://github.com/oomphinc/composer-installers-extender/issues/26#issue..., I managed to make this work by using the following composer plugin: https://github.com/mnsami/composer-custom-directory-installer

So the step to make this work would be:

1 composer require mnsami/composer-custom-directory-installer
2. Add to the "installer-paths" section in "extra" the following:

            "web/libraries/chosen": [
                "harvesthq/chosen"
            ],

I added before "web/libraries/{$name}": [ just in case there are issues in the order, but you can also add it the the current web/libraries/${name}:

            "web/libraries/{$name}": [
              "type:drupal-library",
              "harvesthq/chosen"
            ],

3. composer require drupal/chosen

This should be enough to put the chosen library in the correct destination.

I don't think we should have:
1-Added composer tools
2-Complex instructions on how to install the library

The best way is to follow the default drupal composer process like explained in #45

if I run composer require harvesthq/chosen (D 9) the chosen library will be installed in /libraries/jquery.chosen like any other jquery libraries (/libraries/jquery.xxxxx)

Thus, we ONLY need to update the code in chosen_lib.module / _chosen_lib_get_chosen_path() by prepending 'jquery.' to 'chosen' as showed here:

  if (function_exists('libraries_get_path')) {
    return libraries_get_path('jquery.chosen');
  }
   ....
    if (file_exists($dir . '/jquery.chosen/chosen.jquery.min.js') || file_exists($dir . '/jquery.chosen/chosen.jquery.js')) {
      return $dir . '/jquery.chosen';
    }

Doing this will eliminate all the painful installation steps and avoid any added composer stuff.

Here is the patch which implement #48

composer require harvesthq/chosen would normally put the library in the vendor directory, so I don't think it's quite that simple? What plugin are you using to move it to the libraries directory under the webroot instead?

@james.williams you are completly right... I don't remember how I get it there...
...Thus we need installation steps...
But,
I think that my patch is valid because many jquery plugins are stored with this pattern (libraries/jquery.xxxx)
This could ease the plugins sharing.
Ex: the lang_dropdown module is expecting the chosen library at this place.

@DuneBL I don't believe your patch solves the issue at hand though, sorry. Are you using composer 2? It doesn't put the library under libraries/jquery.chosen either, it puts it outside the webroot under vendor/harvesthq/chosen.

@james.williams sorry, I was not clear enough, my patch doesn't solve the issue, you are right.
You are also right regarding vendor/harvesthq/chosen : this is where chosen will be downloaded.
What I am trying to say is that we should target the ibraries/jquery.chosen folder to be insync with other modules and other jquery libraries which are stored this way.

https://www.drupal.org/project/libraries is the best solution for allowing external libraries to be shared by multiple projects. So if we want to solve that problem, then this module should integrate with that. But that's for a separate ticket, and I don't think should help solve this ticket's problem, as using that to solve this ticket just means adding another dependency.

I think that brings us back to what colan said in comment 43 in response to the suggestion to use & document that asset-packagist.org should be used:

This may be a better idea, but I don't know much about asset-packagist.org so I'll let someone else comment on this approach.

Acquia lightning uses it (see https://lightning.acquia.com/blog/round-your-front-end-javascript-librar...), so does commerce (https://www.drupal.org/project/commerce/issues/2916058) and it's being considered for the drupal-composer/drupal-project composer template project, which even refers to this project in its documentation: https://github.com/drupal-composer/drupal-project/pull/286/files#diff-b3....

I'll also link to these relevant discussions around how this stuff should generally be done in Drupal projects, which are both long-running and not conclusive.
#2605130: Best practices for handling external libraries in Drupal 8/9 and 10
#2873160: Implement core management of 3rd-party FE libraries

In short - the best solutions will be made upstream. In the meantime, major players are using asset-packagist.org - let's do the same here, or at least make it easier for other ways to be used to get the library in place. I propose:

• Remove the requirement of harvesthq/chosen from this module's composer.json
• Add a hook_requirements() to check for the library in the expected location, which should block installation/use of the module if it's not found.
• Add clear documentation (e.g. to the project page, the next release's notes and the readme file in code) that says how we recommend downloading the library - i.e using asset-packagist as in comment 33 and requiring npm-asset/chosen-js in the same way as in that PR for drupal-composer/drupal-project.

How's that?

That all makes sense; thanks for providing the missing context.

the best solutions will be made upstream

If that's true (and obviously I'm in agreement), I'm certainly not clear on why we're not getting any thumbs on that idea (especially since upstream is dead so we won't have to worry about merging all the time). It's the cleanest from a DX (and site-builder experience) perspective as there's nothing special to do when installing the module. It makes all of this go away.

In fact, we probably wouldn't even need to maintain our own fork; just find one that fixes this particular issue, and use that.

I can't answer on #54 as this is outside of my skills. But I think I found why my chosen library was in jquery.xxx: I think this is coming from the webform module...
As this module is handling the chosen library, we could make proposal for a unique destination folder to all the other modules which are using it. (As far I know lang_dropdown and webform... I assume there are others)

I still think, that for the time being, deciding on a proper documentation steps is what's needed. Either npm-assets or what I mentioned on #47 which I am using on several projects now.

Shall we make this a documentation issue and submit a patch? I lost a bit the discussion about creating a fork, would that mean a fork of the actual chosen library? Maybe take that discussion elsewhere?

If that were the case, I would chip in with https://github.com/harvesthq/chosen/pull/2618 which is a long standing PR I have for chosen which obviously needs work as its pretty outdated but I was happy with the solution. Can also attempt to help with maintaining the chosen fork.

Sure - the current options seem to be either:

1) Use a fork of the chosen library itself (making & maintaining one if necessary).

Or:

2) Continue using the current library, which means deciding on the recommended way to use it instead, and updating the documentation for that.

Both options will require at least a change to the module's composer.json file, so even option 2 isn't 'just' a documentation change.

Comments 47 (using mnsami/composer-custom-directory-installer), 54 (npm-asset/chosen-js) and 57 (hanoii's fork) seem to provide the most concrete proposals.

How do we decide? Ultimately, it's probably up to the module maintainers, but I don't think we've heard from them since nagy.balint posted about the video & readme instructions, which no longer work with oomphinc/composer-installers-extender 2.0 (and therefore composer 2).

Good summation, which should be put in the IS.

Aside: I'm pulling out of working on a solution here given my thoughts in #3203875: Consider deprecating module as library is deprecated, and will no longer be helping. This may or may not affect what you folks decide to do here.

Both options will require at least a change to the module's composer.json file, so even option 2 isn't 'just' a documentation change.

With #47 you really don't need any change on either composer.json (module or library). I am installing chosen fine this way.

Oh OK, I see what you mean. So it just makes it necessary for the user to manually add that plugin as a dependency before requiring this module, at least as long as the underlying issue is unresolved?

How do mnsami/composer-custom-directory-installer and oomphinc/composer-installers-extender (and even composer/installers) interact? I feel like because they're doing almost the same job, and both make use of the 'installer-paths' config section of composer.json, they might have unintended conflicts or overwrite each others' behaviour? (Not that I have any actual evidence for that though, just the concern!)

I haven't found any issues. https://github.com/mnsami/composer-custom-directory-installer explains it nicely. Basically this plugin only allows you to move composer packages outside of vendor, it only works with the standard composer types, like library. Not sure how composer-installers-extender will work with library once that issue is fixed, but other than both doing the same, I wouldn't expect any issues.

#47 did the trick for me. I also encountered some library issues with other modules on composer 2. This might resolve that as well.

There is also an open issue for composer installers that seems similar. https://github.com/oomphinc/composer-installers-extender/issues/26

Just saying that comment 47 worked for me also.

easy way

"repositories": [
    ...
    {
      "type": "package",
      "package": {
        "name": "harvesthq/chosen",
        "version": "1.8.7",
        "type": "drupal-library",
        "extra": {
          "installer-name": "chosen"
        },
        "dist": {
          "url": "https://github.com/harvesthq/chosen/releases/download/v1.8.7/chosen_v1.8.7.zip",
          "type": "zip"
        },
        "require": {
          "composer/installers": "~1.0"
        }
      }
    },
    ...
  ],

and

    composer require drupal/chosen

note:

if you install webform dependencies with this method you download chosen library 2 times (libraries/chosen & libraries/jquery-chosen)

Just like #64, the comment 47 fixed the issue for me.

Thanks!

Similar to #27, I straight-up removed everything and reinstalled with ^3.0

composer remove drupal/chosen drupal/chosen_lib

• I then switched to the git download link rather than the direct zip link as suggested in #9.
• I also updated the require and the repository to the most recent version of the chosen library (1.8.something).
• I then had to manually delete the harvesthq folder from /vendor

Then, I required the most recent version of drupal/chosen and ran composer update.

composer require drupal/chosen --no-update
composer update drupal/chosen harvesthq/chosen

And now all the files are in the right place. It's weird. It's almost as if it checks the vendor folder first to see if it exists and just decides to give up if it sees it instead of checking the location it SHOULD be going to.

We could also think about switching to a fork, like https://github.com/jjj/chosen

However I dont see that one on packagist.

As anyways the original chosen is not supported anymore, maybe switching to a fork would be a good idea.

Thanks for finding the fork. I created an issue to suggest to the maintainer to add it on packagist. It should be simple as there is a composer.json already there. See https://github.com/JJJ/chosen/issues/40.

Perfect, thanks!

#33 Worked great for me
composer require bower-asset/chosen

hi
#47 is also the one that worked for me

thanks

Well I see we have 4200 forks of chosen, if somebody has an active one we could use here would be welcome!
https://github.com/harvesthq/chosen/network/members

I think the cleanest solution is in #47, that worked for me as well.

The procedure in comment #47 worked for me (Drupal 9, Composer 2). Thank you to everyone working on this and posting helpful tips.

Until this is resolved, can someone add a link to this thread (and perhaps comment #47) on the main project page so people do not waste time following the steps in the video and current readme file?

Done.
But a working fork would be welcome, so we could make it work out of the box.

I've found a workaround using Drupal Scaffold operations.

I got utterly fed-up of the Chosen library sometimes installing in the right place, and sometimes not, despite having followed the guides above and the work of several other people with the same problems.

As an example, out of the nine D9 sites I maintain - which all use the same composer.json file - Composer on five of the nine sites abjectly refused to put the Chosen library in the correct location, while on the other two sites it worked just fine.

A diff of the composer.jsons between working and non-working sites showed no obvious differences.

So, I'm using Drupal Scaffold as follows:

1: In the root of the repo at the same level as composer.json, I created a build-assets/ directory and added chosen.jquery.js and chosen.jquery.min.js, giving a directory structure of:

./composer.json
./build-assets/chosen.jquery.js
./build-assets/chosen.jquery.min.js

2: In composer.json, in the extra > drupal-scaffold > file-mapping section, add maps which will copy the two Chosen JS files into web/libraries/chosen/ after build:

{
  "extra": {
    "drupal-scaffold": {
      "file-mapping": {
        "[web-root]/libraries/chosen/chosen.jquery.js": "build-assets/chosen.jquery.js",
        "[web-root]/libraries/chosen/chosen.jquery.min.js": "build-assets/chosen.jquery.min.js"
      }
    }
  }
}

(Obviously the above sections in your composer.json will have other entries in them.)

To test, I ran `rm composer.lock; composer install -vvvv` and confirmed that the Chosen files appeared in the correct place, every time.

Hopefully this helps someone else! :)

Alex

Thanks #33 Worked great for me
composer require bower-asset/chosen

FWIW, the fork mentioned in #68 and #69 is now available on packagist. See https://github.com/JJJ/chosen/issues/40.

When we add this new fork to the module, I think that we should create a new branch of the chosen module because it is the only safe way.

- We have already done new branches for modules with minimal changes due to the semver releases.
- We can explain the new branch in the release notes and the module page (and the fact that likely not much needs to be done)
- This would force the site owners to at least check if their sites work properly with the new library, and to make sure that the library is correctly installed, instead of updating with no or minimal checking, and then having an issue somewhere.
- This way we can be sure that this new branch of chosen uses the new fork, and nothing else.

Thanks @carcheky, we would like to confirm solution from #65, based on adding a package to project's composer.json file, fixed the problem.
- Modified the composer file to add package.
- Executed composer require command.
- Verified the files were under the libraries folder

Thanks again to everyone for your great help and feedback on this issue!

New approach here based on wikimedia/composer-merge-plugin. The composer information about the chosen library is stored in a new file named composer.libraries.yml and merged by the mentioned plugin into the main composer information.

This is the way that the Webform module and others, like Toc JS, install their library dependencies.

README.txt updated accordingly.

I've been using this module and have noticed several accessibility issues with the current library (1.8.7). I checked out the fork at https://github.com/JJJ/chosen and it looks like that version (2.2.1) fixes those accessibility issues. As mentioned by @nagy.balint, I think a new branch that just uses this new fork would be a great idea. I guess it doesn't make much sense to keep using 1.8.7 as that repo (https://github.com/harvesthq/chosen) is deprecated.

Ideally what I hoped that we could achieve is to get to a point where if I install the module with -W then it would automatically install the library as well in the correct directory.
Not sure at this point if we can get to that, seeing as it is not defined as drupal library, but nevertheless we could have the new branch to switch to the fork.
Any help is welcome!

I made a new branch.

However for now I could not make it work out of the box. Even if I specify the library as a custom repository (package) it will still not put it in the right directory.
If I copy the same to the main composer.json then it works, so maybe we just need to add some dependency there?

Alternatively we could create a wrapper library, or use the merge plugin.

After further checks, It seems that indeed #82 is the best option.

Will create a patch for 4.0.x in the coming days.

@nagy.balint
I have chosen 3 installed and if I run composer require drupal/chosen:^4.0@RC, I got the following:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/chosen_lib[2.0.0, ..., 2.10.0] require drupal/chosen ^2 -> found drupal/chosen[2.0.0, ..., 2.10.0] but it conflicts with your root composer.json require (^4.0@RC).
    - drupal/chosen_lib[3.0.0, ..., 3.0.5] require drupal/chosen ^3 -> found drupal/chosen[3.0.0, ..., 3.0.5] but it conflicts with your root composer.json require (^4.0@RC).
    - drupal/chosen 4.0.0-rc1 requires drupal/chosen_lib * -> satisfiable by drupal/chosen_lib[2.0.0, ..., 2.10.0, 3.0.0, ..., 3.0.5].
    - Root composer.json requires drupal/chosen ^4.0@RC -> satisfiable by drupal/chosen[4.0.0-rc1].


Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Same thing if I composer remove drupal/chosen before

@DuneBL would composer require drupal/chosen:^4.0@RC -W work any better? (The -W flag encourages composer to update dependencies... in this case, such as drupal/chosen_lib perhaps.)

@james.williams -W doesn't solve this issue

Can you check if your root composer.json contains chosen_lib separately?
Sometimes it gets added there.
Then adding that to the require might help.
composer require drupal/chosen:^4.0@RC drupal/chosen_lib:^4.0@RC -W

#92 solved my issue (FYI no require of chosen or chosen_lib was present in my composer.json as I composer remove drupal/chosen before)

For me the following worked fine on a new install:
composer require drupal/chosen:^4.0@RC -W
And it only added
"drupal/chosen": "^4.0@RC", in the require

However if I then add chosen_lib specifically with:
composer require drupal/chosen_lib:^4.0@RC -W

Then I get
"drupal/chosen": "^4.0@RC",
"drupal/chosen_lib": "^4.0@RC",
In my composer.json

And after that If I do
composer remove drupal/chosen

Then it will throw an error, but it does remove the chosen from my composer.json and leaves chosen_lib there
"drupal/chosen_lib": "^4.0@RC",

And so if at remove chosen_lib is not specifically removed, can perhaps cause issues later when installing updates to chosen.

I came late to this issue queue, but after going through all the comments #47 worked for me.
If you are following comment #17 then you must have composer-installers-extender to be ^1.0 version("oomphinc/composer-installers-extender": "^1.0") otherwise you will get the same error "Package type "library" is not supported"(as per #27).

Just to lay it out, to install drual/chosen (and therefore install jjj/chosen to the correct place) with composer you need to do the following:

1. composer require wikimedia/composer-merge-plugin
2. add the following to the "extra" section of your composer.json:
   

   "merge-plugin": {
     "include": [
       "web/modules/contrib/chosen/composer.libraries.json"
       ]
   },

3. composer require 'drupal/chosen:^4.0' -W

Per https://www.drupal.org/node/3069730 to not use wikimedia/composer-merge-plugin I was able to get drupal/chosen and jjj/chosent to install correctly by:

1) Manually add to "repositories" section

    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "jjj/chosen",
                "version": "2.2.1",
                "type": "drupal-library",
                "extra": {
                    "installer-name": "chosen"
                },
                "source": {
                    "url": "https://github.com/JJJ/chosen.git",
                    "type": "git",
                    "reference": "2.2.1"
                }
            }
        }

2) Then from your project's root directory

composer require 'drupal/chosen:^4.0'
composer require 'jjj/chosen:^2.2'