Update documentation for installing via composer

Adding chosen through composer require drupal/chosen just now also got me submerged into "components", which is slightly unclear what it is (this seems due to the dependency of drmonty/chosen on component/chosen). I am currently still mostly confused about how to get it to work properly.

If anyone can provide a patch with the correct information, then i can commit.

I would prefer for this to be less "involved". Having to define composer packages in your project's composer.json does not make for a smooth install (or maintenance - maybe more important) experience.

I'm not sure what the best approach is, though. There doesn't seem to be an official way to install chosen through composer. The drmorty package seems to be the closest thing, although it simply depends on the components/chosen package, which might be an opportunity to "cut out the middle man". I have gotten it mostly to work by following the instructions of setting an install location for components, found at https://github.com/RobLoach/component-installer. Unfortunately, that still means you need to edit your composer.json, or the components will end up at the root of the project, where the web server will typically not be serving from. Maybe rewording the error message in the config form and the status report are part of the solution too, because they currently seem to assume you will download the library manually (which is actually part of another bug that I should still report; locations of the js and css files don't quite work, with the component way of doing things).

Here is a relevant issue for the Chosen project: https://github.com/harvesthq/chosen/issues/2204 Current status is "will not fix" though.

Hmm, yeah, there's a lot of overlap with that issue. Thanks for the link, it does provide some good arguments against using component-installer. Especially the one about it being a seemingly unrelated line and the trouble of adding comments to composer.json (the number one reason I totally dislike json as a configuration file format). I do expect this to be a problem for more Drupal modules, so maybe some sort of Drupal-wide standard is in order.

Here is another relevant blog post: http://www.nikosams.net/blog/17_composer_npm_bower_assets_installation_u...

Given the numerous solutions out there and none of them having some sort of official status, I suppose adding the repository definition is the most straightforward method, even if quite dirty.

Have a little time to continue with this. Maybe I'm missing something, but shouldn't either one of these changes be included as well:

• Add dependency on harvesthg/chosen
• Add instructions to add dependency on harvesthq/chosen to your project's composer.json (if I am unserstanding correctly, this is the approach that is being taken in #2774237: Manage Leaflet library dependency in composer.json for leaflet

Edit: also, how do we get tests to run correctly when installing the module involves manually editing the root composer.json? (I am not too familiar with the Drupal.org testing infrastructure; I tried finding something about this in de Drupal CI documentation, but couldn't - doesn't mean it isn't there).

Would it make sense to add the requirement of composer/installers inside the repository snippet? That would eliminate one manual step (I was put onto the idea because of dropzone.js, which basically uses the same mechanism, but does include the requirement in the repository definition).

Here's an updated patch. Adding the harvesthq dependency in the module's composer.json is an experiment, I'm not sure how Drupal CI will handle that (then again I'm not sure how it handles any changes to composer.json files).

I changed things around a little bit in the readme and I added the dependency on composer/installers in the library repository entry.

And the actual patch.

This patch re-enters the repository definition in composer.json, in hopes that Drupal CI does something with it even if composer itself doesn't. Probably the last thing to try before removing the dependency entirely and just tell the user to require harvesthq/chosen from their root composer.json.

So there.

Not sure what is going on now, it is mumbling about installing chosen_lib which is contained within the package so shouldn't be something for composer to worry about.

Maybe the test engine is changed? The last branch test that passed was in november.

Could it be that hidden modules are not welcome anymore? #2841739: chosen_lib is hidden

Or maybe it is related to some other change.

Hmm no, the branch passes.

But this patch does not.

I'd still like to see this patch tested with that issue committed.

The good news is that the error about chosen_lib is gone. The bad news is that it is still failing and the error message is a lot less helpful.

Getting rid of some more stuff in composer.json that might confuse Composer.

So currently its ""Composer require failure. Error Code: 255"" I guess.

Is it? Where did you find this? I'll be the first to admit I'm struggling to find the exact problem. What I've been doing is click on the test result badge by the patch (which e.g. now says "PHP 5.5 & MySQL 5.5, D8.3 CI error"), Click on the link "View results on dispatcher" and on the resulting Jenkins screen click through to "Console output" (https://dispatcher.drupalci.org/job/default/299487/console). All I see there is "Installation failed, reverting ./composer.json to its original content." (Or at least, that seems to be the start of the subsequent melt down).

I'm wondering whether this doesn't have anything to do with trying to patch the composer.json and whether it would work fine if these changes were in the composer.json to begin with.

Click on buildstate.json
https://dispatcher.drupalci.org/job/default/299487/artifact/jenkins-defa...

Tested patch #31 against dev branch using composer and it worked fine. Patching was done using composer, I edited the composer.json directly, (following instructions in patched readme.txt), added the module and chosen library and ran 'composer update'.

Chosen module was downloaded correctly and patched and Chosen library ended up in libraries folder. Only issue I still ended up with the components folder generated with chosen library, as per the un-patched composer.json file within the chosen module.

However, i've tested the patched chosen module by placing it in the custom module folder and ran 'composer update' again and the Chosen library is only downloaded to the libraries folder and no components folder is created.

Composer must run all composer.json files before patching, resulting it in running the incorrect pre-patched module composer.json file. I played about with ordering in the root composer file but no luck preventing this behaviour.

Therefore can confirm the patch works and once applied back to dev will solve duplicate download issue with the chosen library. In the meantime ill keep the chosen module in my git repo until this patch is applied to dev.

Thanks for the test, but unfortunately i cannot commit as long as the tests fail on drupal.org as then the branch would not pass anymore after commit..

Well, it seems the the build (not the test, mind you) is failing because composer.json is being patched; if the initial composer.json would be what this patch produces, all would be well (which seems to be corroborated by roborew's findings in #36).

Would it make sense to commit the patch and see how it fares when it is part of the actual branch instead of a patch? It seems highly likely at this point that the test will be fine, in that case. Obviously it should be reverted when it fails in the same manner, but I don't think it will.

@eelkeblok exactly my point, a little less convoluted thanks. Test will pass once the change to the composer file is made. All we be well, this a limitation of patching composer and the testing rig, so will need this slight bending of the rules in this case to help the module pass.

Okay, I will commit it soon.

drupalci/composer facade maintainer here: I just happened to be looking for issues so that I can start to get rid of the CI Error messages and replace them with something more informative, and this caught my eye.

We definitely need to figure out a way to handle declaring assets for modules now that composer has expanded the world of php dependencies. Started some discussion over in the composer facade issue queue: #2843461: Consider creating package data for repository references in modules

The test fails are due to the existing, broken composer.json that the testbot cant work around. Basically, because you've already got a broken composer.json in there, nobody can composer require the chosen module, not even the testbots. I've opened an issue to make this sort of work easier in the future: #2848994: Potentially fallback to git clones for contrib if composer require fails

Committed Thanks!

I'm running composer from Drupal root, relying on wikimedia/composer-merge-plugin, and components/ directory is getting created in root.

Can I add a component-dir directive in my project's composer.json to get this in the right place, or would this require a patch to chosen?

I will make a new release soon.