Problem/Motivation

With core-vendor-hardening present, which is the default, doing a composer install will no longer provide a local composer binary, requiring use of alternate composer installs like a global version, which may of may not be compatible with the project.

This is especially annoying when doing core/contrib work, where this plugin also causes lots of modifications on vendor directories - as is its role - while the root composer.json does not include the config/discard-changes options which would make it more bearable.

Steps to reproduce

Deploy drupal from Git. Do a composer require --dev composer/composer. Try to run vendor/bin/composer : missing.

Proposed resolution

Only strip the composer binary if

  • either the install is run with --no-dev and composer is a dev dependency
  • or composer is installed as a normal (not dev) dependency

Remaining tasks

Evaluate the consequences of this issue.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not yet.

Comments

fgm created an issue. See original summary.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Related issues: +#3108262: Support directories other than vendor in the Hardening Plugin

It's more related to configurability of hardening

Not clear why "deployable payload" may need binary of composer ...cos you need composer to get other version of composer...

mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Status: Active » Closed (works as designed)
Issue tags: +Composer initiative

composer/composer is a dev dependency of core: https://git.drupalcode.org/project/drupal/-/blob/9.0.x/composer.json#L21

The reason it's there is *only* so that we can test core's integration with Composer.

You should have a global installation of Composer, and not rely on Drupal to provide it.

That said, you can add it to your own project if you want. If you're doing development work that won't end up being deployed, you can remove the vendor hardening dependency as well if you don't want it to delete your binary. And there's an option to use drupal/recommended-project instead of the legacy one. It doesn't add the vendor hardening plugin.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

FTR I very much disagree with the "You should have a global installation of Composer" position. Having the site be self-contained using Composer has long been a selling point to clients with quality teams, who want everything below the project root as much as possible.

It's also in line with the removal of global Drush, for the same reasons.

andypost’s picture

andypost
he/him
Primary language Russian
commented

As #3108262: Support directories other than vendor in the Hardening Plugin accepted, it's possible to configure clean-up but possible conflict with core-dev dependencies still looks tricky