Submodule created a package

This is working as designed to prevent a new package from taking over an existing namespace. Since composer only operates on packages, and Drupal has additional dependencies on subcomponents, the subcomponents are made available for dependency resolution with Composer. We of course do not want the possibility of a new module to take over the existing namespace.

@drumm so that means if we have a submodule in any project, and we want to move that out into its own separate module we are forced to change the name of the module? That seems like it could be really disruptive. I was hoping we'd be able to do this with some other popular modules such as webform which contains many submodules that made the D11 upgrade a massive headache.

Or does this only happen when the submodule has its own composer.json?

It’s been suggested in #3304661-8: Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. → that this should be changed.

Or does this only happen when the submodule has its own composer.json?

It impacts all sub-modules.

I do find this counter intuitive that Drupal.org allows me to create a top level project that conflicts with the namespace of a submodule in composer.

The current solution is that the new project gets the namespace drupal/data_pipelines_elasticsearch-data_pipelines_elasticsearch in my example.

Would it not be more intuitive if the submodule got drupal/data_pipelines-data_pipelines_elasticsearch in my example? I assume there is an underlying package manager reason why we need it in the first place; but I can't see it magically causing an issue on an existing site without the developer actually running composer require [package].

We needed to split out the module to support two different APIs concurrently, depending on the site, so there are valid use cases for doing what I did to the modules.

Or does this only happen when the submodule has its own composer.json?

Submodules never have a composer.json, or if they do, nothing reads/uses it. Composer only works at the repository level, reading the composer.json at the root of the project. Packages.Drupal.org also does nothing with composer.json files in subdirectories.

so that means if we have a submodule in any project, and we want to move that out into its own separate module we are forced to change the name of the module? That seems like it could be really disruptive.

In general, we want to make sure people get the same packages for their site deployments. If someone is requiring a submodule, they should keep getting the same submodule. If an arbitrary new project could take the namespace, that would be a giant supply chain security problem.

I feel this is a self-created issue. While I agree that taking over the namespace of an existing package is a supply chain issue... the package probably shouldn't have existed in the first place. The underlying problem is that pseudo packages were created (that actually work) rather than a "This is not the package you seek" type response.

I think it's worth discussing changing the way it works now, rather than letting the problem get worse over time.

🌱 Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. Active is that issue