1

I am trying to use composer correctly to install a library named nikic/php-parser.

Thanks to helpful comments by Clive, I now understand that when a Drupal 7 module comes with a composer.json file, that file is supposed to be merged into a consolidated composer.json-file, and from then on things will be taken care of more or less automatically.

That things are supposed to work that way also follows from this note on the Composer Manager project page:

Composer Manager allows each contributed module to ship with its own composer.json file, listing the module-specific requirements. It then merges the requirements of all found modules into the consolidated composer.json file. This results in a single vendor/ directory shared across all modules which prevents code duplication and version mismatches. [My emphasis.]

The Drupal site where I use for testing is a fresh install of Drupal 7, organized as Drupal 7 is normally organized when you install it using drush (drush si standard).

The Composer Manager package contains a composer.json with the following requirement:

"require": {
    "php": ">=5.3.0",
    "nikic/php-parser": "^4.2"
}

I have the Drupal variable composer_manager_vendor_dir set to sites/all/vendor and the composer directory for the consolidated composer.json is set to /sites/default/files/composer.

The consolidated composer.json currently contains:

{
  "require": {
    "symfony/yaml": ">=3.1",
    "php": ">=5.3.0"
  },
  "config": {
    "autoloader-suffix": "ComposerManager",
    "vendor-dir": "../../../all/vendor"
  },
  "prefer-stable": true
}

I.e., it does not include a requirement for nikic/php-parser. The note from the project cited above seems to imply that it would somehow be merged in automatically. This is yet to happen on my test site.

Following up another hint by Clive, I ran:

drush composer-manager install

This resulted in:

Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
  - Installing symfony/yaml (v3.1.0)
    Downloading: 100%         
Generating autoload files

I.e. it did the updates that was required per the consolidated composer.json. But it did not pay attention to the composer.json in the module's directory.

Trying:

drush composer-manager update

... did not resolve the issue.

There must be something fairly obvious I am missing.

How do I get the requirements in a module's composer.json merged into the consolidated composer.json (apart from splicing it in "by hand")?

6
  • Have you read the module page? Not having a go, it’s just the “How does it work?” section seems to explain quite well where you’ve gone wrong, or more to the point what that module is able to do for you, and how you interact with it (via a module’s composer.json file rather than the command line). If you want to use composer in the command line, I expect you need to use it as normal, it won’t know anything about how your drupal site is organised
    – Clive
    Commented Feb 13, 2019 at 18:14
  • And by that I mean cd /path/to/composer/root; composer require ...
    – Clive
    Commented Feb 13, 2019 at 18:17
  • Sorry, I meant the composer root in your site, not the path to the executable (I think that’s somewhere in sites/default/files by default, but it’s been a long time since I used the module). The automated bit is that it will scan all module folders for a composer.json, merge all the required libraries it finds into one big composer.json file, then download everything as “normal”. I was never under the impression that it was supposed to be used via the command line, just via custom composer.json files in modules. You probably can use it via the command line, composer is flexible, but like...
    – Clive
    Commented Feb 13, 2019 at 18:54
  • 1
    Oh wait, does drush composer-manager install do anything? That just crept into my brain, seems familiar
    – Clive
    Commented Feb 13, 2019 at 19:14
  • 1
    FWIW this module was totally problematic for me. I just use Composer as normal with Drupal 7 without it. Just tell Drupal where the autoloader file is (for vendor classes) so it’s bootstrapped.
    – Kevin
    Commented Feb 14, 2019 at 14:16

1 Answer 1

0

I think I've figured it out.

This is supposed to happen automatically. If the module is enabled with drush under Drupal 7, it does. If you use other means to enable, the module, this might not happen.

In case the root composer.json for some reason is missing the requirements for a specific module, using drush to disable and then again re-enable the module fixes the problem. E.g.:

drush dis composer_manager -y
drush en composer_manager -y

This seems to be all that is required.

It should be emphasised that this is only valid for Drupal 7. Drupal 8 is a completely different beast.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.