Composer project templates do not support drupal-custom-profile installer package type

LGTM.

Strictly speaking, this is not necessary, as a profile should include an example project template of its own in its distribution, so that folks can run composer create-project distro-org/distro-project. The profile routine rules can appear in the distro project template along with any other customizations required for the distro's particular use-case.

I am +1 on including this, though, to serve as a good example of how the profile routing should appear. I'm not really sure why this didn't make it into the initial version of these templates. Having these instructions present enables composer create-project drupal/recommended-project followed by composer require profile-org/profile-project, which is also a viable workflow.

We need to have this apply to 9.1.x and 9.0.x too... unfortunately it doesn't apply.

Here's a patch for 9.x.x

Seems kinda beta-target-y?

The custom locations were provided by https://www.drupal.org/node/2866109

Probably not addressing profiles due to the mistake to relate it to composer/installers releases. Profiles should specify their dependency. That would suggest that composer/installers doesn't belong in the project template but in drupal/core, separate issue I guess.

Popularity of profiles, or rather the lack of, is probably a reason not to include it. Easily added manually, unfortunately not easily configurable with `composer config` AFAIK. No objection to including it, just one line more to remove when you don't want it.

composer/installers must be required as a top-level dependency because otherwise, drupal/core is not placed correctly.

Once we have moved drupal/core entirely to the vendor directory (perhaps scaffolding assets which must be within the docroot), then we can remove composer/installers from the top-level composer.json file.

Obviously, drupal/core doesn't require composer/installers, which causes it to be installed in vendor. Suggest to try with drupal/recommended-project, removing composer/installers. It will still install core in web due to composer/installers being a composer-plugin and drupal/core-recommended having it as requirement.

drupal/core-recommended is not going to have composer/installers as a dependency for much longer. See #3134648: [backport, needs scheduling] Don't pin the composer/installers version in drupal/core-recommended.

Now, ostensibly, making composer/installers a requirement of drupal/core shouldn't work, because Composer needs to install the plugin before it installs a project that the plugin places. However, I did this little experiment, just for fun: (Spoiler: the results were not what I expected.)

$ composer create-project drupal/recommended-project --no-install
$ cd recommended-project
$ vi composer.json # Swap in drupal/core instead of drupal/core-recommended
$ rm composer.lock # Probably not necessary
$ composer update
$ composer why composer/installers
                                                                
  [InvalidArgumentException]                                    
  Could not find package "composer/installers" in your project  

So this is all fine, right? If you don't ask for composer/installers, then you don't get composer/installers, and drupal/core is borked (installed in vendor), right?

Nope.

In the scenario above, drupal/core is still installed in web. 🤪

Go ahead, try it yourself. See if I'm just crazy. I'm not sure why this works. Does Composer support the composer/installers relocations natively now? Part of me thinks I must have made some sort of mistake.

Whew, #12 was a false alarm. drupal/core did get installed to vendor, I just didn't see it. Also, the scaffold files in web confused me.

The dependency on composer/installers of drupal/core-recommended was mentioned just as example, because drupal/core mistakenly doesn't have that dependency.

It works as designed, plugins get priority over other packages upon installation. So, a dependency on composer/installers is going to be installed before drupal/core and active when drupal/core gets installed.
Obviously, this has not been that way in early days of composer. Hence the need to stay current. There probably are issues to tell you to update because of this change.

Custom modules and themes should have the dependency on the version that introduced their module type, just as custom profile should have the dependency on 1.7. It should remain 1.2 for drupal/core.

Obviously, with both removing composer/installers from the project and replacing drupal/core-recommended with drupal/core you end up with drupal/core in vendor. Unless of course you add the dependency where it should have been in the first place, with drupal/core !

In any event, adding composer/installers to drupal/core, if it works, might be a good idea, but it's out of scope for this issue.

#6 still RTBC.

Can only hope core committers agree with me this being a mistake. I'll leave it to them.

I didn't think that #9 said this was a mistake.

#9 addresses two things:
- adding custom profiles destination location
- dependency on composer/installers

- adding custom profiles destination location
No objection to include it. Considering its lack of popularity it probably doesn't belong there.

- dependency on composer/installers
There should be no change in constraint. These projects shouldn't even have the dependency. The dependency on composer/installers belongs to the custom profile, not the project.
As separate issue the dependency should be moved to the appropriate place (drupal/core). I'll leave it also up to them to correct it for custom modules and themes. Assuming the change in constraint then was also wrong, just as it is now. Could be one issue, two or even three.

Or they ignore everything I said and continue as usual.

In general, if you feel that a patch doesn't work or would cause harm, you should set it to "needs work". Drupal already has composer/installers locked to 1.7.0, so I don't think it does any harm to bumping the constraint up. It's possible for users who are not using drupal/core-recommended to use an older version of composer/installers, though, so if this harms your use-case, you could "needs work" this issue.

If you want to suggest something completely different than a given patch, e.g. moving the composer/installers dependency from where it is to a different project, then the best thing to do is to make a new issue and prove that the alternate idea works.

#9 doesn't sound like you're trying to "needs work" the issue because you didn't set the status to "needs work" and you said "no objection to including it". You also have brought up some interesting ideas that should be addressed in another issue. Constructive and clear communication and demonstrative patches are the best way to get the attention of core committers.

As mentioned I'll leave that to the core maintainers. They are just as responsible for the bugs I reported. When they disagree with my reasoning I'll leave it at that.

Had to be re-rolled because we've upped our minimum composer-installers to 1.9 which makes this change even less controversial.

Leaving at rtbc because the only changes here is removing change and fixing the docs to reference 1.9 - which should have been done by #3126566: Allow Drupal to work with Composer 2

For me this is an important change for people new to Drupal. If you use compsoer to create a project based on drupal/core-recommended and then composer require an install profile the install profile should be put into the correct place. ATM it is not.

That is what is happening at the moment, see distribution varbase. It is using a profile typed drupal-profile. This issue is about type drupal-custom-profile. Guess that people knowing how to create a custom profile, know how to configure it to the right destination.

Not aware of any custom profile, can someone provide an example?

Ah @mmjvb I see. Okay so I think we should actually review our approach to profiles.

I'm not sure I can see the argument for contrib directory inside profiles.

            "profiles/contrib/{$name}": ["type:drupal-profile"],

As someone who works on Thunder I've always raised an eyebrow at this because most projects are only ever going to have one folder in profile and even if we do ever do profile inheritance (something I'm known for being very unkeen on) you're never going to have the explosion of profiles in this folder.

So might we consider changing it to:

            "profiles/{$name}": ["type:drupal-profile"],

And then we can be done as both contrib and custom profiles can declare their type to be drupal-profile and they'll end up in the right place.

@joegraduate Thanks for confirming the type is actually used. Wonder about the motivation for using it. Any particular considerations?
Are you saying those types declared for drupal in composer/installers NEED to be mapped, regardless its use? That policy would make sense to me.

Obviously, you would require a repository to provide those extensions. Should the project contain such a repository declaration ( private/path)? What would it be?

Do these custom profiles have the requirement on the proper version of composer/installers? Or did you decide to set it as requirement for all projects?

@joegraduate thanks for the info. In that case I'm fine with proceeding with #22. I'm not wild about drupal-profile and drupal-custom-profile existing but as they already and are in use then it makes sense to support it.

Per #28, reviewed again and feel this is RTBC.

While there is no need to separate profiles in a site between custom and contrib (since most sites don't use more than one profile), folks with custom profiles feel odd about putting their custom code into a directory called "contrib". While this is not an operational problem, it's clearer to be consistent with themes and modules.

I think it's better to have this in the default templates for clarity.

Adding issue credits

Committed cedf38f and pushed to 9.1.x. Thanks!

Discussed this with @mixologic

I didn't backport this because I think that could cause some disruption in this scenario

* custom profile in a repo x
* project that includes ^ profile via composer
* deploy tooling that adds the profile

In that scenario, I think this change could cause the location of a profile to change with this patch

Happy to be wrong, but erring on the side of caution.

Since these directives are only in the template project, the location of the profile wouldn't change unless the deploy tooling involved calling composer create-project, which I think would be unusual.

I don't think there's a strong need to backport this, though, as folks can always copy the directive into their sites directly if they need it.

Might be worthy of highlights?