Have to run composer install twice to make custom installer paths work #6

jfarthing84 · 2016-07-27T00:42:07Z

I hope this is not something just on my end. For some reason or another, I have to run composer install twice, in order to get packages to go where they are assigned in composer.json. That is, it has to be run once initially, and then it appears each subsequent run works as expected.

Also, after the initial composer install, all packages go to the vendor directory.

The text was updated successfully, but these errors were encountered:

jfarthing84 · 2016-07-27T14:06:07Z

It's probably worth noting, that the packages are using custom types, as defined in the installer-types array in the project's composer.json:

{
    "config": {
        "preferred-install": "dist",
        "vendor-dir": "htdocs/vendor"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "git@bitbucket.org:jfarthing84/vanilla-theme.git"
        },
        {
            "type": "vcs",
            "url": "git@bitbucket.org:jfarthing84/vanilla-plugin.git"
        },
    ],
    "require": {
        "php": ">=5.5",
        "oomphinc/composer-installers-extender": "^1.1.1",
        "jfarthing84/vanilla-theme": "dev-master",
        "jfarthing84/vanilla-plugin": "dev-master"
    },
    "extra": {
        "installer-types": ["vanilla-plugin", "vanilla-theme"],
        "installer-paths": {
            "htdocs/web/app/plugins/{$name}/": ["type:vanilla-plugin"],
            "htdocs/web/app/themes/{$name}/": ["type:vanilla-theme"]
        }
    }
}

jfarthing84 · 2016-07-27T17:42:58Z

For reference, here's the theme's composer.json:

{
  "name": "jfarthing84/vanilla-theme",
  "description": "A theme for Vanilla.",
  "keywords": ["vanilla", "theme"],
  "license": "GPLv2",
  "authors": [
    {
      "name": "Jeff Farthing",
      "email": "jeff@jfarthing.com",
      "homepage": "https://jfarthing.com"
    }
  ],
  "type": "vanilla-theme",
  "extra": {
      "installer-name": "VanillaTheme"
  },
  "require": {
    "php": ">=5.3",
    "composer/installers": "^1.1"
  }
}

And here's the plugin's composer.json:

{
  "name": "jfarthing84/vanilla-plugin",
  "description": "A plugin for Vanilla.",
  "keywords": ["vanilla", "plugin"],
  "license": "GPLv2",
  "authors": [
    {
      "name": "Jeff Farthing",
      "email": "jeff@jfarthing.com",
      "homepage": "https://jfarthing.com"
    }
  ],
  "type": "vanilla-plugin",
  "extra": {
      "installer-name": "VanillaPlugin"
  },
  "require": {
    "php": ">=5.3",
    "composer/installers": "^1.1"
  }
}

balbuf · 2016-07-27T18:39:14Z

Hey Jeff! Thanks for providing all the details - I will try look into this soon. Could you also confirm what version of composer you're on?

jfarthing84 · 2016-07-27T19:05:07Z

Composer version 1.2.0 2016-07-19 01:28:52

jfarthing84 · 2016-07-28T14:07:28Z

To further clarify, I did some additional tests.

Starting out, the vendor directory doesn't exist. The first composer install puts all packages into the vendor directory. If I then remove the vendor directory and run composer install again, the same thing happens. However, if I leave the vendor directory and run composer install again, the packages end up where they are supposed to.

Also, just creating an empty vendor directory before the initial composer install makes no difference.

Does this plugin just copy the package from the vendor directory to the desired location? If so, that would halfway explain this...

balbuf · 2016-07-28T14:42:07Z

Hi Jeff - thanks for the additional information. I haven't had a chance to look into this yet but hopefully I will soon. The installer does not copy from vendor but instead installs directly to the destination(s) you configure in your composer.json file.

It would also be helpful for me to know if you have an global plugins at play. If you could provide me the output from composer global show -D that would be great. Thanks!

jfarthing84 · 2016-07-28T14:44:06Z

$ composer global show -D
Changed current directory to /home/jeff/.config/composer
Composer could not find a composer.json file in /home/jeff/.config/composer
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section

balbuf · 2016-07-28T14:47:32Z

My first hunch has that there is another installer that is taking precedence over this plugin, but it appears you don't have any global plugins installed. Thanks for sending along the info regardless!

jfarthing84 · 2016-07-28T15:23:05Z

It is very important for me to get this working correctly ASAP - so anything I can do, let me know!

balbuf · 2016-07-28T15:27:56Z

If the intended effect is had after running composer install twice, while not "correct", shouldn't that work for you for now?

jfarthing84 · 2016-07-28T15:28:41Z

I suppose so...

jfarthing84 · 2016-07-28T17:36:07Z

Another observation: Delete composer.lock and run composer install and all packages go where expected. Delete all the packages that were just installed, keeping the composer.lock that was just generated, run composer install again and everything goes into vendor.

pascalek · 2016-09-06T11:49:27Z

This probably is related to the order composer installs packages. Try adding oomphinc/composer-installers-extender to the required section of packages you are installing. This solved it in my case.

jfarthing84 · 2016-09-14T19:29:33Z

I actually got composer/installers to merge my pull request to support Vanilla. So, I'm good now - though this is still a bug.

dwenzel · 2017-01-26T18:12:44Z

I can confirm this issue:
Library packages are installed into vendor/<vendor name>/<package name>/ directory instead of
<library path>/<package installer name> on first composer install.
If I do a second composer install or composer update, packages are moved to the expected path. (some duplicates remain in the vendor path though).

If the package composer.json requires oomphinc/composer-installers-extender everything works fine on first install.

This is my working setup:
Package composer.json

{
  "name": "fooVendorName/bar-legacy-userfunc",
  "description": "....",
  "type": "legacy-fileadmin-library",
  "require": {
    "oomphinc/composer-installers-extender": "^1.1"
  },
  "extra": {
      "installer-name": "userfunc"
  }
}

Main composer.json

{
  "name": "foo/bar",
  "description": "...",
  "config": {
    "vendor-dir": "app/vendor",
    "preferred-install": {
      "*": "dist"
    }
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "git@path-to-legacy-package/userfunc.git"
    }
  ],
  "require-dev": {
    "fooVendorName/bar-legacy-userfunc": "dev-develop"
  },
  "extra": {
    "installer-types": ["legacy-fileadmin-library"],
    "installer-paths": {
      "app/web/fileadmin/{$name}/": ["type:legacy-fileadmin-library"]
    }
  }
}

Package fooVendorName/bar-legacy-userfunc is being installed to app/web/fileadmin/userfunc

stefanruijsenaars · 2017-02-27T16:25:22Z

This probably is related to the order composer installs packages. Try adding oomphinc/composer-installers-extender to the required section of packages you are installing. This solved it in my case.

This fixed the issue for me (see
openfed/openfed8-project@aa2b773)

Can we rename this issue to "Have to run composer install twice to make custom installer paths work" so it's more easily findable in the issue queue? And maybe make a note in the README as well?

daften · 2017-03-15T20:11:40Z

I'm having the same issue, putting this package in require doesn't help me.

phenaproxima · 2017-03-29T13:09:29Z

I have this problem as well! But I am not in control of the packages I'm requiring, so I can't add this to their required sections...not sure how to proceed with this.

landsman · 2017-04-20T14:08:02Z

I have same problem and I want requiring 3rd party packages like chosen.
Is here some working solution?

balbuf · 2017-04-22T17:23:54Z

Hi everyone - I apologize that we have not been able to address this any sooner! I've done some digging through the composer's source and I believe I have a working solution.

TL;DR: move "oomphinc/composer-installers-extender" to the top of your require section, or at least before any packages that need to be installed to a custom path.

The explanation:
Typically composer will move plugins to the front of the line when installing packages, as these plugins might affect how other packages are installed (e.g. custom installers); see: https://github.com/composer/composer/blob/master/src/Composer/Installer.php#L745. However, plugins that have dependencies other than composer-plugin-api are not moved. In the case of this plugin, it has composer/installers as a dependency and thus is not moved to the front. What this means is that other packages might be installed before composer-installer-extender is installed and run and thus are not installed to the correct location. On the second execution of composer install, composer-installer-extender is already installed and will correctly place the packages in their custom paths.

In my testing, this issue is avoided by putting "oomphinc/composer-installers-extender" as the first dependency in the require section, or at least before any other dependencies that will be installed to a custom path.

Consider these examples:

Example 1

{
    "name": "oomphinc/composer-test",
    "require": {
        "psr/log": "*",
        "oomphinc/composer-installers-extender": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is installed to vendor/ instead of off-the-beaten-path/

Example 2

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/

Example 3

{
    "name": "oomphinc/composer-test",
    "require-dev": {
        "psr/log": "*"
    },
    "require": {
        "oomphinc/composer-installers-extender": "*"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/ (require dependencies are installed before require-dev dependencies)

This seems to be a working fix - please try this approach and report back if it still does not work for you so I can continue troubleshooting. If it works consistently then I can update the readme to include this information.

Ultimately a true fix lies within composer itself, and I'm going to take a look to see what can be done there.

phenaproxima · 2017-04-26T12:32:01Z

Thanks, @balbuf, for your detailed response! However, I'm sorry to have to report that the fix you suggested doesn't seem to be working for me. Here is my composer.json, with the irrelevant parts removed:

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "license": "GPL-2.0+",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "extra": {
	"installer-types": ["library"],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "enyo/dropzone"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.0",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "enyo/dropzone": "^4.3"
    },
}

Have I missed something? (Hopefully :) But with this composer.json, enyo/dropzone is still installed in vendor/enyo/dropzone.

kasperg · 2017-05-01T09:32:43Z

I tested the composer.json provided by @phenaproxima and I see the same result: enyo/dropzone is still installed in vendor/enyo/dropzone.

I am mostly interested in this projects in correlation with https://asset-packagist.org. I tried with with the following adjustments (resulting json below):

Add https://asset-packagist.org as repository
Replace library with npm-asset in installer-types
Replace enyo/dropzone with npm-asset for docroot/libraries/{$name}
Change "enyo/dropzone": "^4.3" to "npm-asset/dropzone": "^4". For some reason I could not grok Composer does not recognize the 4.3.0 package and gets 4.2.0 instead.

Using this approach Dropzone ended up in docroot/libraries/dropzone/.

However if I subsequently delete the vendor and docroots folder but not composer.lock then Dropzone ends up in vendor/npm.asset/dropzone. In this case npm-asset/dropzone is also mentioned before oomphinc/composer-installers-extender in the Composer install log. Running composer install again will move Dropzone to docroot/libraries as per the original issue description.

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "license": "GPL-2.0+",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    ],
    "extra": {
        "installer-types": ["npm-asset"],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "type:npm-asset"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.0",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "npm-asset/dropzone": "^4"
    }
}

kasperg · 2017-05-01T11:45:35Z

I started digging a bit more. As far as I can tell the situation is related to the specificity of version constraints.

Expanding on the examples by @balbuf:

Example 4

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "1.0.2"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is installed to vendor/ instead of off-the-beaten-path/. Reinstalling from lock file will put files in the correct position.

Example 5

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "*",
        "psr/log": "^1.0"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/. Reinstalling from lock file will keep files in the correct position.

Example 6

{
    "name": "oomphinc/composer-test",
    "require": {
        "oomphinc/composer-installers-extender": "1.1.2",
        "psr/log": "1.0.2"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "off-the-beaten-path/{$name}/": ["type:library"]
        }
    }
}

psr/log is properly installed to off-the-beaten-path/. Reinstalling from lock file will keep files in the correct position.

phenaproxima · 2017-05-01T15:53:59Z

I tried a few things and wanted to report on what has finally worked for me. As @kasperg said, tweaking the version constraints seems to have a positive effect. Here's my abbreviated composer.json, which installs things to the right place:

{
    "name": "acquia/lightning",
    "description": "The best of Drupal, curated by Acquia",
    "type": "drupal-profile",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        }
    ],
    "extra": {
        "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/libraries/{$name}": [
                "type:bower-asset",
                "type:npm-asset"
            ],
            "docroot/profiles/lightning/modules/contrib/{$name}": [
                "type:drupal-module"
            ]
        }
    },
    "require": {
        "cweagans/composer-patches": "^1.5.0",
        "oomphinc/composer-installers-extender": "^1.1",
        "drupal/core": "~8.3.1",
        "drupal/embed": "^1.0",
        "drupal/entity_embed": "1.0.0-beta2",
        "drupal/media_entity": "^1.0",
        "drupal/media_entity_instagram": "^1.0",
        "drupal/media_entity_twitter": "^1.3",
        "drupal/media_entity_image": "^1.0",
        "drupal/ctools": "^3.0",
        "drupal/panels": "^4.0",
        "drupal/page_manager": "^4.0",
        "drupal/panelizer": "^4.0",
        "drupal/scheduled_updates": "1.0.0-alpha6",
        "drupal/workbench_moderation": "1.2.0",
        "drupal/acquia_connector": "^1.1",
        "drupal/config_update": "^1.1",
        "drupal/features": "^3.0",
        "drupal/inline_entity_form": "^1.0",
        "drupal/metatag": "^1.0",
        "drupal/token": "^1.0",
        "drupal-composer/drupal-scaffold": "^2.0.0",
        "drupal/pathauto": "^1.0",
        "drupal/entity_browser": "1.0.0",
        "drupal/views_infinite_scroll": "^1.1",
        "drupal/media_entity_document": "^1.0",
        "drupal/video_embed_field": "^1.0",
        "drupal/contact_storage": "^1.0",
        "drupal/diff": "^1.0",
        "drupal/entity_block": "1.0.0-alpha2",
        "drupal/search_api": "^1.0",
        "drupal/layout_plugin": "^1.0@alpha",
        "bower-asset/dropzone": "^4",
        "drupal/dropzonejs": "1.0.0-alpha6"
    }
}

With this, bower-asset/dropzone is installed in docroot/libraries/dropzone, after deleting the lock file and running composer install. Making the dropzone constraint more specific (e.g., ^4.3) breaks it. Dunno what's up with that, but there you go.

phenaproxima · 2017-05-02T17:49:07Z

I've done a little more testing and discovered that Composer really does seem to be utterly non-deterministic about installation order for anything (including this package) that has more listed dependencies than php and composer-plugin-api. I can make this work on my local machine, but on Travis CI, the exact same composer.json things in the wrong location (bower-asset/dropzone comes first, then much later, oomphinc/composer-installers-extender -- meanwhile, composer/installers always goes straight to the front).

I'm not sure this can be solved at all until composer/composer#6371 is merged.

balbuf · 2017-05-03T17:44:13Z

I really appreciate all the additional investigative work! It does appear that, arbitrarily, certain factors such as version specificity and composer.json order have influence on whether this issue manifests itself, but ultimately the install order cannot be reliably controlled in that way. Thus, that is not a viable workaround unfortunately.

I'd like to see if we can get composer/composer#6371 merged as the preferred solution, as that would reliably fix the issue for this plugin and any others out there that have their own dependencies.

Failing that, I would consider removing composer-installers as a dependency itself and replicate the underlying functionality that this plugin relies on, but I would consider that a last resort.

landsman · 2017-05-08T19:11:27Z

Thank you for your work! I have some idea: What about some response message back to the bash about moving these vendors, packages? Is it possible?

landsman · 2017-05-08T19:58:27Z

I don't know what I am doing bad, but right now it not working at all.

Jelle-S · 2017-05-19T08:51:05Z

FYI: installing this plugin globally solves the issue as well.

rodrigoaguilera · 2017-05-21T19:24:49Z

With following composer.json I can't make bootstrap-sass to install in a custom path.
I tried changing the order of the requires, installing plugins globally, playing with the versions, running composer update and install several times.

Am I missing something

{
    "name": "oomphinc/composer-test",
    "repositories": [
	{
		"type": "composer",
		"url": "https://asset-packagist.org"
	}
    ],
    "require": {
        "oomphinc/composer-installers-extender": "1.1.2",
        "psr/log": "1.0.2",
        "bower-asset/bootstrap-sass": "3.3.7"
    },
    "extra": {
        "installer-types" : [ "library" ],
        "installer-paths": {
            "otherpath": ["bower-asset/bootstrap-sass"],
            "thispath": ["psr/log"],
            "morepaths": ["type:npm-asset"]
               
        }
    }
}

It always get installed into vendor

rodrigoaguilera · 2017-05-22T09:56:22Z

Forget about that last comment, my "installer-types" was missing npm-asset and bower-asset as explained in the about page for that repo
https://asset-packagist.org/site/about

raubin · 2017-05-22T18:06:47Z

Ok, thanks for the update @rodrigoaguilera !

balbuf · 2017-05-23T17:45:33Z

That is a great point @Jelle-S.

The issue here is that occasionally composer-installers-extender is not loaded and executed early enough; global plugins are always executed before the project composer.json is acted upon. Thus composer global require oomphinc/composer-installers-extender is a valid workaround; however, the implication is that this is going to be acting on every project whether or not it actually uses composer-installers-extender, and in some cases this could take precedence over other custom installers that a project actually intends to use. The other drawback is that this must be done before the regular composer install within the project, and it must be done manually by each user (only once though). Bottom line, this workaround could be helpful to some, but it does come with some drawbacks.

In the meantime, I am working with the composer folks to address the root issue there, and hopefully that can be worked out soon.

balbuf · 2017-06-12T16:55:59Z

Hi all! I just wanted to provide an update that the composer folks have accepted our pull request (composer/composer#6371) which fixes the issue detailed in this thread. This fix is slated to be part of the 1.5 version release of composer, but it is unclear when that will drop.

In the meantime, you can use the update immediately by upgrading composer to the latest snapshot:

composer self-update --snapshot

This will upgrade composer to the latest snapshot of the master branch, which includes the fix for this issue. Be aware that this is not considered a stable release, so there could be bugs that haven't been worked out yet. However, it would be helpful to see if this fix works in all cases outlined above, so I encourage anyone willing to perform the upgrade and report whether this effectively resolves the issue.

If you'd like to just test the fix and go back to your previous installed version of composer, you can do so with:

composer self-update --rollback

or you can update to the latest stable release:

composer self-update --stable

maosmurf · 2017-07-20T09:40:47Z

Hi,
please find minimal non-working demo at https://github.com/kurier/composer-bower-assets-order

First composer install puts bower-asset to vendor, only after second subsequent composer install the package is placed in correct folder.

balbuf · 2017-07-20T15:24:14Z

Hi @maosmurf - did you try upgrading composer to the latest snapshot release (composer self-update --snapshot) and try to install? There is a potential fix in composer's master branch but there has not been an official release that includes this yet.

maosmurf · 2017-07-20T17:14:22Z

Hi @balbuf - I can confirm that issue is solved in current composer snapshot (1.5-dev (189ba423aedc387a0487df40afc2428947406327) 2017-07-20 10:08:41)

Package of type bower-asset is placed correctly on first run of composer install, subsequent calls to composer install result correctly in "Nothing to install or update"

Thank you!

kasperg · 2017-08-08T09:58:17Z

Composer 1.5 is out now with the fix and I just confirmed that it still works for https://github.com/kurier/composer-bower-assets-order.

Thanks for your work @balbuf. I guess we can close this issue now. 🎉

cfoellmann · 2017-09-19T15:03:54Z

I am about to give up. I use this composer.json

{
    "name": "vendor/project",
    "description": "tbd",
    "type": "project",
    "config": {
        "preferred-install": "dist"
    },
    "license": "internal-only",
    "repositories": [
        {
            "type": "composer",
            "url": "https://www.phpmyadmin.net"
        }
    ],
    "require": {
        "oomphinc/composer-installers-extender": "^1.1",
        "phpmyadmin/phpmyadmin": "*"
    },
    "extra": {
        "installer-types": ["application"],
        "installer-paths": {
            "phpmyadmin/": ["phpmyadmin/phpmyadmin"]
        }
    }
}

and it doesn't work.

If I use

{
    "name": "vendor/project",
    "description": "test",
    "type": "project",
    "config": {
        "preferred-install": "dist"
    },
    "license": "internal-only",
    "authors": [
        {
            "name": "Christian Foellmann",
            "email": "foellmann@foe-services.de"
        }
    ],
    "require": {
        "oomphinc/composer-installers-extender": "^1.1",
        "wp-cloud/phpmyadmin": "*"
    },
    "extra": {
        "installer-types": ["application"],
        "installer-paths": {
            "phpmyadmin/": ["wp-cloud/phpmyadmin"]
        }
    }
}

it works just fine.
This uses a phpmyadmin package modified to be of the type application. But since the package from the phpmyadmin repo is now multi-language enabled I wanted to drop my own repo.

Any idea why I can't custom install the library type from the phpmyadmin repo?

daften · 2017-09-19T16:54:49Z

@cfoellmann I think that is a different issue than the one discussed here. I'd suggest opening up a separate issue for this :)

balbuf · 2017-09-19T18:06:18Z

@cfoellmann yes if you could open a new issue for this that would be great; I'm going to close this issue as there have been no new reports of the problem described herein since the release of Composer 1.5.

Nick-Hope · 2018-11-11T07:33:51Z

I am still suffering this problem with Composer 1.7.3 (in Ubuntu 18.04). The harvesthq/chosen library will not install in my web/libraries directory, no matter what I try; it always goes to the vendor directory. It won't even go there if I run composer update or composer install twice. As far as I can tell I have tried everything suggested in this thread. "Chosen" was specifically mentioned in this comment above by landsman, so maybe it is something specific to that package. Here's my composer.json in full. Note that I have already tried without harvesthq/chosen specified in the installer-paths section.

{
    "type": "project",
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },
        {
            "type": "package",
            "package": {
                "name": "jackmoore/colorbox",
                "version": "1.6.4",
                "type": "drupal-library",
                "dist": {
                    "url": "https://github.com/jackmoore/colorbox/archive/1.6.4.zip",
                    "type": "zip"
                }
            }
        }
    ],
    "require": {
        "composer/installers": "^1.5",
        "oomphinc/composer-installers-extender": "^1.1.2",
        "cweagans/composer-patches": "^1.6.5",
        "drupal-composer/drupal-scaffold": "^2.5",
        "drupal/admin_toolbar": "^1.24",
        "drupal/allowed_formats": "^1.1",
        "drupal/better_exposed_filters": "^3.0@alpha",
        "drupal/chosen": "^2.6",
        "drupal/colorbox": "^1.4",
        "drupal/console": "^1.0.2",
        "drupal/core": "^8.6.3",
        "drupal/ctools": "^3.0",
        "drupal/facets": "1.1",
        "drupal/field_permissions": "^1.0@rc",
        "drupal/geolocation": "2.x-dev",
        "drupal/hierarchical_term_formatter": "^1.0@beta",
        "drupal/image_style_quality": "^1.3",
        "drupal/media_taxonomy_filter": "2.x-dev",
        "drupal/pathauto": "^1.3",
        "drupal/quicktabs": "^3.0@alpha",
        "drupal/search_api": "^1.10",
        "drupal/search_api_autocomplete": "^1.1",
        "drupal/shs": "^1.0@alpha",
        "drupal/superfish": "^1.2",
        "drupal/taxonomy_manager": "^1.0@alpha",
        "drupal/taxonomy_menu": "^3.3",
        "drupal/token": "^1.5",
        "drupal/tvi": "^1.0@beta",
        "drupal/video_embed_field": "^2.0@alpha",
        "drupal/views_arg_order_sort": "1.x-dev",
        "drupal/views_contextual_filters_or": "^1.0",
        "drupal/views_infinite_scroll": "^1.5",
        "bower-asset/jquery-ui-slider-pips": "^1.11.4",
        "jackmoore/colorbox": "^1.6.4",
        "vlucas/phpdotenv": "^2.5.1",
        "webflo/drupal-finder": "^1.1",
        "webmozart/path-util": "^2.3",
        "wikimedia/composer-merge-plugin": "^1.4.1",
        "harvesthq/chosen": "^1.8"
    },
    "require-dev": {
        "drupal/devel": "^1.2",
        "webflo/drupal-core-require-dev": "^8.6.2"
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "config": {
        "preferred-install": "dist",
        "autoloader-suffix": "Drupal8"
    },
    "autoload": {
        "psr-4": {
            "Drupal\\Core\\Composer\\": "core/lib/Drupal/Core/Composer"
        }
    },
    "scripts": {
        "pre-autoload-dump": "Drupal\\Core\\Composer\\Composer::preAutoloadDump",
        "post-autoload-dump": "Drupal\\Core\\Composer\\Composer::ensureHtaccess",
        "post-package-install": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
        "post-package-update": "Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup",
        "drupal-phpunit-upgrade-check": "Drupal\\Core\\Composer\\Composer::upgradePHPUnit",
        "drupal-phpunit-upgrade": "@composer update phpunit/phpunit phpspec/prophecy symfony/yaml --with-dependencies --no-progress",
        "phpcs": "phpcs --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --",
        "phpcbf": "phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer --"
    },
    "extra": {
        "_readme": [
            "By default Drupal loads the autoloader from ./vendor/autoload.php.",
            "To change the autoloader you can edit ./autoload.php.",
            "This file specifies the packages.drupal.org repository.",
            "You can read more about this composer repository at:",
            "https://www.drupal.org/node/2718229"
        ],
        "enable-patching": true,
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset",
                "harvesthq/chosen"
            ],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"],
            "web/modules/custom/{$name}": ["type:drupal-custom-module"],
            "web/themes/custom/{$name}": ["type:drupal-custom-theme"]
        },
        "drupal-scaffold": {
            "initial": {
                ".editorconfig": "../.editorconfig",
                ".gitattributes": "../.gitattributes"
            }
        },
        "merge-plugin": {
            "include": [
                "core/composer.json",
                "web/modules/custom/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-extra": false,
            "ignore-duplicates": true
        },
        "patches": {
            "drupal/core": {
                "Render action button above parent entity": "https://www.drupal.org/files/issues/preview-comment-aoutput-below-2927874-2.diff",
                "Hide undefined index errors on all pages": "https://www.drupal.org/files/issues/filterpluginbase-filter-notices.patch"
            },
            "drupal/geolocation": {
                "Respect initial zoom value": "https://www.drupal.org/files/issues/2018-11-02/geolocation-respect-initial-zoom-level-2945234-60.patch"
            },
            "drupal/facets": {
                "Display titles on slider facets": "https://www.drupal.org/files/issues/2018-10-18/3002580_6.patch"
            },
            "drupal/views_arg_order_sort": {
                "Fix SQL injection attack vulnerability": "https://www.drupal.org/files/issues/2018-10-19/views-arg-order-sort-sql-injection-fix-2982591-5.patch"
            }
        }
    }
}

balbuf · 2018-11-11T20:58:22Z

Hi @Nick-Hope, I opened a new issue and will respond there: #16.

I am going to lock this conversation to avoid bothering folks on this thread. For anyone that comes across this issue and experiences something similar, please open a new issue! (Feel free to reference this issue if appropriate.) Thank you!

balbuf added the bug label Jul 27, 2016

jurgenhaas mentioned this issue Dec 4, 2016

Custom paths don't seem to work hiqdev/asset-packagist#20

Closed

balbuf changed the title ~~Have to run composer install twice~~ Have to run composer install twice to make custom installer paths work Mar 31, 2017

landsman mentioned this issue Apr 20, 2017

Added closed PR #5 BurdaMagazinOrg/thunder-project#12

Closed

balbuf mentioned this issue Apr 22, 2017

Move all plugins and their dependencies to the front composer/composer#6371

Merged

rodrigoaguilera mentioned this issue May 22, 2017

Install an asset to a custom path hiqdev/asset-packagist#51

Closed

thebrandonallen mentioned this issue Jul 22, 2017

PHPCS composer.json needs phpcodesniffer-standard Varying-Vagrant-Vagrants/VVV#1239

Merged

balbuf closed this as completed Sep 19, 2017

leymannx mentioned this issue Sep 20, 2018

Abandon project in favour of oomphinc/composer-installers-extender davidbarratt/custom-installer#9

Open

balbuf mentioned this issue Nov 11, 2018

Package not installing to correct location #16

Closed

oomphinc locked as resolved and limited conversation to collaborators Nov 11, 2018

Have to run composer install twice to make custom installer paths work #6

Have to run composer install twice to make custom installer paths work #6

Comments

jfarthing84 commented Jul 27, 2016 • edited

jfarthing84 commented Jul 27, 2016 • edited

jfarthing84 commented Jul 27, 2016

balbuf commented Jul 27, 2016

jfarthing84 commented Jul 27, 2016

jfarthing84 commented Jul 28, 2016 • edited

balbuf commented Jul 28, 2016

jfarthing84 commented Jul 28, 2016

balbuf commented Jul 28, 2016

jfarthing84 commented Jul 28, 2016

balbuf commented Jul 28, 2016

jfarthing84 commented Jul 28, 2016

jfarthing84 commented Jul 28, 2016

pascalek commented Sep 6, 2016

jfarthing84 commented Sep 14, 2016

dwenzel commented Jan 26, 2017 • edited

stefanruijsenaars commented Feb 27, 2017

daften commented Mar 15, 2017

phenaproxima commented Mar 29, 2017

landsman commented Apr 20, 2017

balbuf commented Apr 22, 2017

phenaproxima commented Apr 26, 2017

kasperg commented May 1, 2017 • edited

kasperg commented May 1, 2017

phenaproxima commented May 1, 2017 • edited

phenaproxima commented May 2, 2017 • edited

balbuf commented May 3, 2017

landsman commented May 8, 2017 • edited

landsman commented May 8, 2017

Jelle-S commented May 19, 2017

rodrigoaguilera commented May 21, 2017

rodrigoaguilera commented May 22, 2017

raubin commented May 22, 2017

balbuf commented May 23, 2017

balbuf commented Jun 12, 2017

maosmurf commented Jul 20, 2017

balbuf commented Jul 20, 2017

maosmurf commented Jul 20, 2017

kasperg commented Aug 8, 2017

cfoellmann commented Sep 19, 2017 • edited

daften commented Sep 19, 2017

balbuf commented Sep 19, 2017

Nick-Hope commented Nov 11, 2018

balbuf commented Nov 11, 2018

jfarthing84 commented Jul 27, 2016 •

edited

jfarthing84 commented Jul 27, 2016 •

edited

jfarthing84 commented Jul 28, 2016 •

edited

dwenzel commented Jan 26, 2017 •

edited

kasperg commented May 1, 2017 •

edited

phenaproxima commented May 1, 2017 •

edited

phenaproxima commented May 2, 2017 •

edited

landsman commented May 8, 2017 •

edited

cfoellmann commented Sep 19, 2017 •

edited