Silverstripe-framework: Composer v2 will not work on fresh installs of Silverstripe CMS v3 projects

[unclecheese]

Affected Version

Silverstripe CMS < 4.2

Description

When cloning an existing Silverstripe CMS v3 project built with Composer 1, (with vendor/ and module directories excluded, per usual), running the composer install command with Composer 2 installs all the modules to vendor/, e.g. vendor/silverstripe/framework, which will fail in this version of the CMS.

If running composer update, it works fine.

If you delete the composer.lock file, it works fine.

Creating a new silverstripe/installer:^3 project works fine.

Steps to Reproduce

$ git clone myworkspace/my-ss3-project-with-a-composer1-lockfile myproject
$ cd myproject
$ composer install

See that everything is in vendor/, including framework, cms, etc.

[unclecheese]

Marked this as a bug and a docs issue. I'm leaning toward no fix, but just provide clear comms on what to do in this situation (delete composer.lock).

Note that composer says the lock file _should_ be BC, but they may not have accounted for our use case of "type": "silverstripe-module".

[ScopeyNZ]

If running composer update, it works fine.

Creating a new silverstripe/installer:^3 project works fine.

Is there much impact in this bug if those two still work fine? I'm thinking I should just give you this copy paste:

Unfortunately, SilverStripe 3 has entered limited support in June 2018. This means we'll only be fixing critical bugs and security issues for SilverStripe 3 going forward.

You can read the SilverStripe Roadmap for more information on our support commitments.

[sminnee]

I'd suggest that anyone still using Silverstripe 3 pins themselves to composer 1 if they run into issues.

[unclecheese]

The major case where this would happen is in a deployment. You've got a project you've been working on in Composer 1, then one day you upgrade to composer 2.. make some changes, deploy, and your script is something like:

$ git clone ... /tmp/my-project
$ cd/ tmp/my-project
$ composer install

7,000 files will be deleted
7,000 files will be added

[ScopeyNZ]

type/docs? I think the fix here would be probably way too complicated for a "might happen" on SS3.

[Cheddam]

To me, this seems like a bug in Composer? I'm not sure how we'd even approach fixing this in our codebase(s) - the incorrect behaviour occurs during a Composer process, before any of our code runs.

+1 on documenting as an edgecase. The only action we could really take beyond that would be raising an issue against Composer itself, and hoping they're interested in fixing it (or producing a patch ourselves.)

[unclecheese]

I see it as a documentation issue, as well. But I'm not sure how edge-casey it is. Checking out a project and doing composer install is about as mainstream as it gets, and the only variance would be that you've upgraded your composer binary since the composer.lock was generated. Given that 2.0 has just come out, I _suspect_ we'll see quite a few of these.

[ScopeyNZ]

Oh I missed that it already had the type/docs label 🤦

[unclecheese]

If I had labelled it console.log, would you have spotted it? 😂