Use custom composer type instead of "project"

[mathieuhelie]

"Project" is meant to be used for packages that can be applied to composer create-project. Drupal-VM is a dependency. We should create a custom type called "drupal-vm" so that we can specify where it's installed in our projects.

[geerlingguy]

@mathieuhelie - Do you mean in the main Drupal VM composer.json, here: https://github.com/geerlingguy/drupal-vm/blob/master/composer.json

The tough thing is, some people use Drupal VM standalone, others use it included as part of an upstream project (e.g. a BLT-built Drupal project)... I want to favor the standalone use case, and in that case, wouldn't project make more sense?

[mathieuhelie]

This is the issue where the purpose of composer's "project" type was determined:
composer/composer#1142

Using "project" here means we are creating a project out of the Drupal-VM composer.json file, adding dependencies (such as Drupal core) there.

The Vagrantfile pass-through feature would imply the opposite, that we are importing Drupal-VM into the project and customizing it from local yml config files. We can then keep Drupal-VM updated with composer update, which we cannot do if it was transformed into a project.

As it stands, running composer create-project geerlingguy/drupal-vm myproject does a local checkout of Drupal-VM but does not clone the repository. I don't think that's what anyone is doing. We need to keep the VM up to date in terms of roles, at the very least.

[mathieuhelie]

Using composer create-project geerlingguy/drupal-vm myproject --prefer-source will get you a full clone of the drupal-vm history, but you can also do this with a custom package type, for example drupal-core. (PS do not try this on drupal/core, it will clone drupal but also fully clone all dependencies.)

[oxyc]

I think @mathieuhelie is correct. Let me just write down how I believe it works.

Currently we have the following setups documented:

1. The default uses composer create-project, which does not use composer.json.
2. A custom composer.json, which uses drupal.composer.json rather than composer.json
3. Drupal VM used as a dependency. This is the scenario @mathieuhelie describes where project is in fact the wrong type.

So we never suggest that anyone should use Drupal VM's own composer.json. We briefly thought about the idea of including a one line quick start guide for the people who have composer. But I don't think this was ever added. The only reason it's set to project is because I thought that was the convention when you want to allow for composer create-project geerlingguy/drupal-vm myproject. I based this on bedrock.

@mathieuhelie you're saying composer create-project geerlingguy/drupal-vm myproject works regardless of the type? If that's the case I agree that we should change it. Using Drupal VM as a dependency is probably far more common than using an IDE scaffolding feature (described in the issue @mathieuhelie linked to).

I can also verify that laravel/homestead can be scaffolded using create-project even if it's just a regular package type. Composers documentation also uses the word package.

To create a new project using Composer you can use the "create-project" command. Pass it a package name, and the directory to create the project in.

https://getcomposer.org/doc/03-cli.md#create-project

[geerlingguy]

To promote potential parity with other VM-related projects, I'd like to use the custom type vm, and that way you can still do custom logic based on it, and it should still work with composer create-project.

More docs for reference: https://getcomposer.org/doc/04-schema.md#type