It's helpful to understand how Composer works and how to best utilize the environment as you implement your PSR-0 Namespace. There are factors that you, where you, as a user of the environment, will not be able to change and you should be aware of those points. There are areas where your choices directly impact the folder path and the implementation of your namespace.

##Composer Name Parameter##

The first data relevant to the package install path is the name provided Composer.

###What is the purpose of the name parameter?###

Composer requires a two-part, lowercase name that serves as a unique key for installing the package.

This two-part name represents the vendor name and the package name.

You enter these values into the name parameter of your package composer.json file.

In many cases, the same value is used for vendor name and package name.

These values are used as a key to locate a package in the package repository. (Most use Packagist for this purposes and match the name entered there.)

###Install path and folders###

Composer uses the literal vendor and the two-part name to begin the install path to your package.

    vendor/vendor-name/package-name

###Examples###

vendor/molajo/filters

vendor/monolog/monolog

vendor/symphony/http-foundation

###Relevance to Namespacing###

Since the Composer name is required in lowercase, it is unlikely that you will find it is useful as a node in your package namespace.

If you enter the same value for Vendor name as Package name, that value will still be used two times in the install path.

It is important to remember that the purpose of this data is to enable Composer to use it as a key to locate and install packages.

##Composer target_dir parameter##

Next, Composer uses the value entered as target-dir to extend the path and folder structure.

A folder is created for each node in the target-dir value.

vendor/vendor-name/package-name/Values/Provided/In/Target/Dir

###Example:###

vendor/symphony/http-foundation/Symfony/Component/HttpFoundation

###Relevance to Namespacing###

If your package folder structure does not contain the beginning of your namespace, you can use target-dir to add nodes needed to implement your namespace.

If your package folder structure contains the entirety of your namespace (or if you were able to reuse the lowercase Composer name as the start of your namespace), you do not need to provide a value for target-dir.

##3. Your Package Repository##

Finally, Composer copies in the folders and files from your package repository at the current location of the install path.

If you did not specify a target_dir, that location begins:

vendor/vendor-name/package-name/

If you specified a target_dir, that location begins:

vendor/vendor-name/package-name/Values/Provided/In/Target/Dir/

###Install Path Examples with Package Folder Inclusion### Each folder in your repository becomes a folder and part of the install path. If your package repository looks like this:

doc
  etc
src
  Packagename
		Folder1
		Folder2
		Folder3
			Class1
tests
	etc

Path to Class1 if you did not specify a target_dir, that location begins:

vendor/vendor-name/package-name/src/Packagename/Folder3/Class1

Path to Class1 if you did specify a target_dir, that location begins:

vendor/vendor-name/package-name/Values/Provided/In/Target/Dir/Packagename/Folder3/Class1

###Namespace Implications### Given good knowledge of the facts above, consider the best way to implement your namespace. There are ways to minimize the folder structure, if such is a concern.

There are ways to organize collections of software for those vendors with many packages. There is data needed by Composer to install your package with other software.

##Conclusion## It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.

###Advice to achieve the minimum install path, possible

1. Leverage the Composer name key, if you can use lowercase nodes in your namespace.
2. Do not use a value with target_dir.
3. DO not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)

Following that advise, a minimal package install path will look like this:

vendor/vendorname/packagename/VendorName/PackageName/Class

Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation.

• It would be nice, for example, if it were easier to reuse the Composer primary key as part of the namespace in mixed case.
• If Composer did not use the same value for name twice in the path.
• If one were able to install a package from a subfolder.

But, as is true with our own software, incremental improvements, code in hand, people willing to help solve problems, etc., is the way the things advance. Patience is always appreciated.

In the broader scheme of things, Composer and PSR-0 are ushering in a level of coordination that is quite remarkable and it is good that your work will now be a part.