Drupal does not have a standard Composer package name policy (that I am aware of). Because of this, we could encounter a scenario in which Composer package names conflict (we kind of already are).

For instance, in core/lib/Drupal/Component/README.txt it says:

In other words, only dependencies that can be specified in a composer.json file of the Component are acceptable dependencies. Every Drupal Component presents a valid dependency, because it is assumed to contain a composer.json file (even if it may not exist yet).

In #2176065: Introduce a composer.json for Drupal\Component\Utility a composer.json was added that uses the package name:


which makes perfect sense.

Also, in #1975220: Allow a Composer user to manage Drupal, modules, and PHP dependencies with a custom root composer.json, two package names are added:


for Drupal core and:


for Drupal proper.

None of these at this point conflict, however, every idea presented in #1886820: Packagist for Drupal Projects (and Commerce's composer.json) uses the pattern:


This also makes perfect sense (especially for projects hosted on

Where things stop making sense is that we have Drupal components that conflict with existing modules:
Diff & Diff
Datetime & Datetime

Proposed resolution

Composer only allows for package names like so:


You cannot use more than two levels. :(

Drupal already has an existing namespace based on:

because of this, any project (drupal, core, profiles, modules, themes, etc.) should be in this namespace:


Examples: becomes drupal/drupal becomes drupal/core becomes drupal/datetime becomes drupal/views

Some of these URLs don't exist, or point to other modules, but Drupal wont let you run two modules with the same name anyways, so that is irrelevant. Also, like in the case of Views, the version numbers are completely different. When #2456009: Add a "replace" section to core/composer.json lands, if you specify drupal/views as your dependency, that dependency will be resolved with drupal/core (as it should be). Although, in the future, it might be a good idea for to reserve those namespaces (and preferably post subtree splits to them).

The only problem then, is Components, which are not required to live in the existing Drupal namespace.

These components should be prefixed with their parent's name:


Datetime becomes drupal/core-datetime
Diff becomes drupal/core-diff

This also allows contrib to expose components like so:

Since the - (dash) is not used in the existing drupal namespace, it shouldn't conflict in anyway to what is currently in Drupal.

Remaining tasks

  1. Make a decision Composer package name standard and document it.
  2. Ensure that existing composer.json files meet that standard

API changes

Any composer.json files that reference the old names will need to be updated. As far as I know there are none in core, but there might be some in contrib already.

Beta phase evaluation

Unfrozen changes Unfrozen because it really only has implications for the naming of Composer-based packages in Drupal\Component.
Disruption Potentially disruptive to infrastructure outside Drupal, depending on what's decided. Existing Composer-based build systems might need to rename their packages.
#48 drupal_composer_policy-2401519-48.patch1.62 KBdavidwbarratt
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 96,390 pass(es). View
#45 drupal_composer_policy-2401519-45.patch1.61 KBderhasi
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal_composer_policy-2401519-45.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more


davidwbarratt’s picture

Issue summary: View changes
davidwbarratt’s picture

Issue summary: View changes
davidwbarratt’s picture

Issue summary: View changes
davidwbarratt’s picture

Issue summary: View changes
dawehner’s picture

Diff & Diff
Datetime & Datetime

Please help me: Drupal\Component\Datetime vs. Drupal\datetime, Drupal\Component\Diff vs. Drupal\diff
How is that causing conflicting namespaces?

catch’s picture

Priority: Critical » Major
Status: Active » Postponed (maintainer needs more info)

Same question as #5. The issue summary doesn't explain what the practical issue is, or why it's critical.

bojanz’s picture

The question is about composer package names, not code namespaces.

davidwbarratt’s picture

Title: [policy, no patch] Decide on Composer Namespaces » [policy, no patch] Decide on Composer Package Names
Issue summary: View changes

I apologize, I used the wrong terminology, I am in fact talking about Composer package names, not PHP Namespaces.

Please see:

I've updated the Title & Issue Summary to fix my mistake.

This issue ought to be Critical because a decision needs to be made before Drupal 8 is released.

davidwbarratt’s picture

Priority: Major » Critical
Status: Postponed (maintainer needs more info) » Active

Changing back to Active & Critical, if it shouldn't be Critical, please change to something more appropriate. :)

derhasi’s picture

Yes, I think we are talking about package names :)

In the composer context we should clarify the meaning of the drupal vendor. Is it the whole community, only code from or only code from drupal core? Currently there are already some packages of the drupal vendor. I'm not sure if we should (or even if it is possible to) restrict creation of "drupal/"-packages by anyone on packagist.

In the Drupal environment we have many concepts that can become a Composer package or are one already:

  • A full Drupal project
  • Drupal core and the Drupal core distribution
  • Install profiles and Drupal distributions based on a install profile
  • Drupal modules
  • Drupal themes
  • Drupal Drush extensions (like drush_language)
  • 3rd party libraries

With the type property of a composer.json we already could technically distinguish the types of a package (see Composer installers).

The main problem we may get is, when a module or component of core (or an installation profile) might hold the same name as a contrib module. The diff component of D8 core would be named drupal/diff as well as the contrib module might be called drupal/diff. This is "only" a problem because we are thinking of "drupal/" as the overall vendor prefix.

I do not think we should have different vendor prefixes (or prefixed package names) for each different type of Drupal package (see list above). I think we should use different vendors for distinguishing the source of the code, whether it is a component from Drupal core, a Project hosted on (module, theme, profile) or a third party library hosted on github. Because of this I think we should use vendor prefixes like this:

  • drupal-core/: For components and modules used within drupal core and created by the drupal core team
  • drupal-org/: For projects on any project that is available at[name] would have the name drupal-org/[name]. This could be achieved by a custom packagist we are already working on.
  • [author]/: A author prefix should be used by anything that is not created by the drupal core team and is not hosted on

I ignored drupal/ for now on purpose, as that vendor is to unclear at the moment, but maybe should be a replacement for drupal-core once we decide on the approach.

With #1886820: Packagist for Drupal Projects we already have some work going on for autogenerating composer information for projects. So there will be no need to publish each drupal module and theme to

catch’s picture

kim.pepper’s picture

Issue summary: View changes

Added beta phase evaluation to summary.

dawehner’s picture

Sorry for mixing things up.

While this might be relevant for quite some cases when people publish their modules, I don't see why this could block Drupal 8.0.x from being released ...
Beside from that I think it is certainly valid to discuss it!

Dave Reid’s picture

We already have a natural separation of project types on, so I would think that we have a natural fit for that:

For example we have the following project types:
Distribution project (drupal-dist/*)
Drupal core (drupal/*) project (drupal-org/*)
Module project (drupal-module/*)
Theme Engine project (drupal-theme-engine/*)
Theme project (drupal-theme/*)

It might be good to lump modules, theme engines, and theme projects all together into the same Composer vendor namespace since naturally modules and themes cannot share the same name. So maybe a drupal-contrib/* vendor namespace?

bojanz’s picture

Following that logic, perhaps drupal-extension/ for modules and themes?

derhasi’s picture

As I understand, on projects share the same "namespace", so no project of one type can share the same name with a project of another type (on From that perspective, I do not think we need different vendors for those different project types. In composer we can distinguish those different types by using composer type in composer.json. Drupal-packagist could do that automagically for any project on d.o .

From my perspective the main task is how we distinguish Drupal projects (hosted on d.o, like modules, themes, core, ...) from code components used in and created for those projects, such as submodules, subthemes and PHP components. Most of them (look at all contribs) may never be released as separate packages. But anyways I think that the "author" of that code should be the first indication for the vendor name.

In terms of the Drupal core components we could think of the Drupal core team as the author for those. So drupal-core could be a vendor for code initially created for Drupal core, but with the goal of releasing it as a separate component. The same approach could be used for core themes, modules and profiles.

For Drupal contrib components, we should not have any conflicting situation, as names of submodules and subthemes should not conflict with other modules or themes. PHP Components that are created for contrib projects should not use any of the drupal vendors at all, IMHO, as those mostly are either tightly coupled to the module itself and are not reusable or they are reusable and should be included in the authors vendor.

So from my perspective adding drupal-core would highlight the drupal core contributions to the PHP world and would avoid disappearance in a maybe clutterin up drupal vendor.

Introducing a separate single vendor (like drupal-contrib) would be helpful for an auto-generating Drupal Packagist. But that would be something to discuss seperately, for a contrib guideline in terms of "Should I post my module to". If there is a working Drupal Packagist, that step might not be necessary.

webchick’s picture

Priority: Critical » Major
Issue tags: -needs Drupal 8 critical triage

"This is a critical issue becuase a package name policy should be established before Drupal 8's release to avoid naming conflicts now or in the future."

Sorry, I don't think so. To review the definition of critical:

Critical bugs include those that:

Render a system unusable and have no workaround.
Cause loss of data.
Expose security vulnerabilities.
Cause tests to fail in HEAD on the automated testing platform, since this blocks all other work.

I think it's fine to try and resolve this before release, but in the event we don't, things being named inconsistently is only mildly inconvenient, and would not block the release of Drupal 8.

I would call this issue "normal," but splitting the difference as "major."

webchick’s picture

Issue summary: View changes
fago’s picture

I'd consider this as a critical part of the the d8 infrastructure, but let's fix better make sure it gets fixed instead of arguing about the priority.

I don't think we should add the project type to the vendor prefix, even it's part of the namespacing - that's not what the vendor prefix is made for. It should tell me the source of the package, not its type.

In the composer context we should clarify the meaning of the drupal vendor. Is it the whole community, only code from or only code from drupal core?

I think we need to bring the existing concept of approved projects hosted on d.o. to composer - (regardless what exactly that means or not). Thus, I think we need a general vendor prefix for everything approved of d.o., while sandboxes shouldn't get that prefix.

Currently there are already some packages of the drupal vendor. I'm not sure if we should (or even if it is possible to) restrict creation of "drupal/"-packages by anyone on packagist.

I do not know, but that seems to be an important issue to me in order to be able to gain the same amount of trust into drupal/* (or whatever prefix will end up with) packages as there is for drupal projects. How does e.g. symfony handle this?

So from my perspective adding drupal-core would highlight the drupal core contributions to the PHP world and would avoid disappearance in a maybe clutterin up drupal vendor.

Yeah, regardless of the namespacing a drupal-core vendor would make sense to me as well as there is way different process and level of trust behind those packages imo.

PHP Components that are created for contrib projects should not use any of the drupal vendors at all, IMHO, as those mostly are either tightly coupled to the module itself and are not reusable or they are reusable and should be included in the authors vendor.

I'm not sure about that, e.g. if we'd manage to make Rules re-usable it's still a package authored by multiple contributors and not me alone. So then, there would be drupal/rules for the module and a component - why shouldn't that be drupal/rules-core as well? It's a component authored by the same people, so shouldn't be the vendor be the same?

Related, there is also no clarification the right package type for drush yet, see

Crell’s picture


drupal/* - Any module or theme or whatever from (They already share a namespace due to Drupal's architecture, so no sense breaking them up.)
drupal-core/drupal - Drupal core itself, the whole shebang.
drupal-core/* - A Drupal core component (Plugins, Utility, Datetime, etc.)

That keeps the number of vendors down to just 2, clearly establishes drupal/* as "stuff that gets mirrored from", and drupal-core as the "core team owns this" vendor. It's also super easy for people to remember.

Non-Drupal-coupled components that are not part of core... should just be on Packagist themselves in their own vendor namespaces.

In Symfony's case, the "symfony" namespace is reserved for the Symfony Git repo (aka, Fabien owns it). Bundles (the Symfony framework equivalent of modules) are in whatever their author's vendor namespace is. Many are in the FOS (FriendsOfSymfony) namespace, but many are also in some random person's GitHub username vendor. I think for Drupal we want to keep the "collective ownership" approach and use drupal/* rather than Crell/*, webchick/*, fago/*, etc.

Mile23’s picture

+1 on drupal and drupal-core for vendor names in #20.

Also, when it comes to sub-types, +1 on #10 using composer installers. The 'type' property already knows how to route these things as long as everyone requires composer/installers:

Any architectural changes to Drupal can be upstream changes to composer/installers.

More complex installation requirements can be turned into composer plugins if needed. Probably not though.

Basically: If you think we need a complex system for naming things or organizing things, you're doing it wrong.

dawehner’s picture

I'm +1 on the propsal of #20, but honestly I don't care much, IMHO its more important that we have a decision than what the decision is.

davidwbarratt’s picture


How would we deal with the Datetime Component:
and the Datetime module:

I think your proposal would mean they would both be:



Crell’s picture

David: I'd first ask why those even exist. It seems a silly split to make.

Baring that, I'd note that the odds of us splitting a core *module* (rather than core *Component*) out to its own packagist package are extremely remote, unless we were to move all of Drupal to be built via Composer (which is not on the table for D8, but totally should be a D9 priority). Even then, it's a module so we may as well reuse the module vendor namespace: drupal/datetime, classes in \Drupal\datetime.

davidwbarratt’s picture


I think there's certainly a legitimate use-case for splitting modules. For instance, you could use some of the classes in the Searlization module, and you don't really need Drupal core at all. :) (ok, some of the classes you do, but you get my point).

Anyways, that can be for another day, but I think they should be able to be treated like any other module in contrib (i.e. you should be able to specify a core module as a dependency of your module in your composer.json file).

However, setting the modules in core to be drupal/ is fine with me and I think it makes it consistant with the contrib modules.

How would your proposal deal with these two?
would they become:





davidwbarratt’s picture

Crell’s picture

Debatable. I'm inclined to say that Drupal itself should be an exception, since drupal/drupal is dead simple to remember and consistent with many other projects. (symfony/symfony, guzzlephp/guzzlephp, etc.)

Looking at those files though... wha? If the intent is that the top level composer.json file is the "user editable" one, why would that have the name drupal/drupal? Shouldn't that be something project specific, or at least not the key Drupal name?

(Symfony's standard install project has a name of symfony/framework-standard-edition, and then symfony/symfony is a dependency.)

derhasi’s picture

When we follow the current Drupal naming process for modules, themes, profiles/distributions, they are all unique (or should be) even if they are only a submodule or subtheme of a project. With this approach we could deal with "drupal/" as the vendor for all projects and subprojects being hosted on, that share this unique namespace due of Drupal's extension approach. For example: everything that currently can be downloaded with drush dl ... or enabled with drush en ... can use the name "drupal/...". This also would include the "Drupal core distribution" being "drupal/drupal".

As "Components" are not part of this unique namespace those should be split into a separate vendor "drupal-core". The same should be for the D8 core and named "drupal-core/drupal" or "drupal-core/core".

Following that rule we would end up with "drupal/datetime" being the core module and "drupal-core/datetime" being the PHP component developed by the drupal core team.

This approach also should not be a problem for "drupal/views" as we can distinguish the source for contrib (D7) and core (D8) by the version. Therefore we even can provide the module as one package, pointing to contrib for D7 and pointing to a metapackage for D8.

I'm not sure about that, e.g. if we'd manage to make Rules re-usable it's still a package authored by multiple contributors and not me alone. So then, there would be drupal/rules for the module and a component - why shouldn't that be drupal/rules-core as well? It's a component authored by the same people, so shouldn't be the vendor be the same?

@fago: following this approach, submodules, -themes or -profiles could live in "drupal/". For separate non-Drupal-Components you could introduce "drupal-rules" for the Rules Team.

Following the "symfony/"-approach, "drupal-core" could be our "symfony/", that would highlight the Drupal core contributions. Using "drupal/" for the whole Community (projects provided on therefore can be seen as the trusted source for Drupal "extensions".

davidwbarratt’s picture

The drupal/drupal namespace is used for the composer create-project command:
a user can do something like this:

composer create-project drupal/drupal my-drupal-site/ 8.*

which will download drupal and run composer install

drupal/drupal is actually based on this namespace:
and drupal/core is based on this namespace:
which used to be page before it was converted into a redirect in #1789896: Redirect project/core to project/drupal. However, I think the url/namesapce will be used to hold the subtree split with #2352091: Create (and maintain) a subtree split of Drupal core.

Our naming convention better matches Laravel than Symfony:
Project: laravel/laravel
Framework: laravel/framework

Basically, what I've learned from the last few posts is... we already have a working, unique namespace based on:
which translates to:

That's all fine with drupal, core, and any module for that matter, but it breaks down with the components which (some) have the same name (or could have the same name in the future).

I also asked myself.. "What if a module wants to expose Components? What would the namespace be for that?"

And I believe I have a solution...

For Components, it will be the name of the component, prefixed by the parent that hold the component.

For Drupal Components this would look like:
and the datetime module would still be:

This allows modules to expose Components as well like:

Since underscores are used in the module names and dashes are used to seperate it from a component, there shouldn't be any conflict.

Does this resolve all of the concerns?

davidwbarratt’s picture

Issue summary: View changes
Status: Active » Needs review

I've updated the issue summary. If someone could review the proposal and see if it fits all the use cases you can think of, that would be amazing. :)

davidwbarratt’s picture

Issue summary: View changes
davidwbarratt’s picture

If someone could update the "Beta phase evaluation" that would be amazing. I don't think this should be as disruptive with the current proposal since it only changes Components.

davidwbarratt’s picture

Issue summary: View changes
Mile23’s picture

+1 for the most part.

For overlaps I'd suggest one of two options:

  1. The d.o project wins, so that d.o/project/diff becomes drupal/diff, whereas Drupal\Component\Diff becomes drupal/component-diff, and in fact we'd need to just go ahead and always add the component- part to all components for consistency.
  2. d.o contrib-flavored projects have a vendor of drupal-project, so we have drupal-project/diff and drupal/diff.

I kind of prefer the latter because drupal-project is a bit like saying 'contrib.' It's not Drupal, but an extra add-on type thing.

Either way, is workable, though.

If I were writing a library that was part of a contrib project, I'd put it on github and call it mile23/whatever, and then it would be a dependency of my contrib project, and thus avoid the namespace issue altogether.

Mile23’s picture

Issue summary: View changes
Mile23’s picture

davidwbarratt’s picture


There's already been a lot of talk about having the "type" in the name see #10 and #19. Basically, it's a bad practice, and I agree.

For this reason, we should not use drupal/component-NAME since the "component" part does not tell you where it comes from, it tells you it's "type". Also, there is no way to know where the component is (i.e. is it in core? a contrib module? a theme?)

While you might host a library in your module on GitHub (and call it whatever you want). I think contrib modules should (in the future), be given the ability to subtree split their modules (on d.o.) so that outsiders can take advantage of the components.

These components should be able to use the same naming structure as core does.

For these reasons (and many others outlined in this thread) components should be:


i.e. drupal/core-diff

which tells you exactly where the component comes from:
core project
diff component
and does not have any sort of "type" in it.

davidwbarratt’s picture

Is there any additional feedback? If not, could someone please mark this as RTBC? :)

Crell’s picture

Status: Needs review » Reviewed & tested by the community

I don't know who exactly needs to approve this; probably one of the committers. So pushing it onto their radar. Let's get a move on.

alexpott’s picture

The latest proposal makes a lot of sense to me. Can we identify whihc page of the handbook we're going to document this and do we have any composer documentation in core code that needs an update?

davidwbarratt’s picture


I would think it would go on this page (or perhaps a new subpage of this one)?

derhasi’s picture

Assigned: Unassigned » derhasi
Issue summary: View changes
Issue tags: +composer

I did not find any composer documentation in core, so no need for an update there.

As deals with PHP Namespaces only, we should not mix that up with a naming convention for composer. I would create a separate Page "Composer package naming convetion" (with "Coding Standards" being the parent) for review now.

derhasi’s picture

Assigned: derhasi » Unassigned
Status: Reviewed & tested by the community » Needs review

I created the documentation page on

As I added some text (e.g to try to clarify the "submodule"-situation), this needs a review again.

derhasi’s picture

Issue tags: +drupaldevdays
derhasi’s picture

Title: [policy, no patch] Decide on Composer Package Names » [policy] Decide on Composer Package Names
Related issues: +#2211633: Provide a composer.json file for Drupal\Component\Plugin, +#2472269: Fix syntax errors in Drupal\Component\Plugin's composer.json, Add test
1.61 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal_composer_policy-2401519-45.patch. Unable to apply patch. See the log in the details link for more information. View

With #2211633: Provide a composer.json file for Drupal\Component\Plugin already landing, we actually need a patch in this issue. Therefore updating the title and adding the patch due to the convention discussed so far.

Looking at the patch, the core team maybe wants to go with the drupal-core vendor. This would be fine with our convention, as components are not forced to use drupal. For now I added the drupal/core- variant.

The syntax error of the composer.json is handled in #2472269: Fix syntax errors in Drupal\Component\Plugin's composer.json, Add test

davidwbarratt’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #45 looks good to me. :)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 45: drupal_composer_policy-2401519-45.patch, failed testing.

davidwbarratt’s picture

Status: Needs work » Needs review
1.62 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 96,390 pass(es). View


hussainweb’s picture

Status: Needs review » Reviewed & tested by the community

Setting to RTBC as per #46.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 3f95bfc and pushed to 8.0.x. Thanks!

Can someone make sure the relevant updates have been done to the handbook page.

  • alexpott committed 3f95bfc on
    Issue #2401519 by davidwbarratt, derhasi: [policy] Decide on Composer...
tstoeckler’s picture

Sorry, I don't know if the proposal was changed at some point or if this was already discussed above, but I always thought that we would use drupal/component-utility for Drupal\Component\Utility. Specifically because there is also a Drupal\Core\Utility. Now that drupal/core-utility is already taken there is no name that comes to mind for the latter.

Am I missing something?

davidwbarratt’s picture


See #37 for a full explanation.

The composer namespaces are not going to match up to the php namespaces. We gave up knowing where something is in core (which should only apply to components anyways) for knowing where something is in core and conbrib. Since Drupal\Core\Utility is not a component, it will never have a composer.json or a subtree split anyways, so there is no need to accommodate it for a namespace. So now drupal/core-utility is Drupal\Component\Utility and Drupal\Core\Utility does not get a composer namespace since it is not a module nor a component.

davidwbarratt’s picture


Also see #29.

davidwbarratt’s picture


Lastly, if there are classes/methods you want to use and are generic in Drupal\Core\Utility, then we should create a new issue to move those classes/methods into Drupal\Component\Utility.

alexpott’s picture

Yep Drupal\Core\Utility will never be a separate thing in Composer.

tstoeckler’s picture

Hmm... I was afraid that thar was going to be the answer. That's a little bit disappointing.

...but still yay for this change in general.

And thanks for the clarification!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Balu Ertl’s picture

To all whom are subscribed to follow this issue:

The Docs page Composer package naming conventions references this issue as "WIP". However issue status is "Closed (fixed)". Can we remove those lines from the top of the docs page, maybe?