The main repository, when it comes to Composer packages, is Packagist (https://packagist.org). It is a web service that we can access through our browser, open an account on for free, and start submitting our packages to the repository. We can also use it to search through already existing packages.

Packagist is generally used for free open source packages, though we can attach privateGitHub and BitBucket repositories to it in the same manner, the only difference being that the private repositories require SSH keys in order to work.

There are more convenient commercial installations of the Composer packager, such as Toran Proxy (https://toranproxy.com). This allows easier hosting of private packages, higher bandwidth for faster package installations, and commercial support.

Up to this point, we sliced our applications into six different Git repositories, one for core application and the remaining five for each module (catalog, customer, payment, sales, and shipment) individually. Now, let's take the final step and see how we can move away from the Git submodules to the Composer packages.

Assuming we created an account on https://packagist.org and successfully logged in, we will start by clicking on the Submit button, which should land us on a screen similar to the following screenshot:

Here, we need to provide a link to our existing Git, SVN, or Mercurial (HG) repository. The preceding example provides a link (https://github.com/ajzele/B05460_CatalogBundle) to the Git repository. Before we press the Check button, we will need to make sure that our repository has a composer.json file defined in its root, otherwise an error similar to the one shown in the following screenshot will be thrown.

We will then create the composer.json file for our CatalogBundle with the following content:

{
"name": "foggyline/catalogbundle",
"version" : "1.0.0",
"type": "library",
"description": "Just a test module for web shop application.",
"keywords": [
"catalog"
  ],
"homepage": "https://github.com/ajzele/B05460_CatalogBundle",
"license": "MIT",
"authors": [
    {
"name": "Branko Ajzele",
"email": "ajzele@gmail.com",
"homepage": "http://foggyline.net",
"role": "Developer"
    }
  ],
"minimum-stability": "dev",
"prefer-stable": true,
"autoload": {
"psr-0": {
"Foggyline\\CatalogBundle\\": ""
    }
  },
"target-dir": "Foggyline/CatalogBundle"
}

There are quite a lot of attributes here, all of which are fully documented over on the https://getcomposer.org/doc/04-schema.md page.

With the preceding composer.json file in place, running the composer install command on console will pull in the code under the vendor/foggyline/catalogbundle directory, making for a full path of our bundle file under vendor/foggyline/catalogbundle/Foggyline/CatalogBundle/FoggylineCatalogBundle.php.

Once we add the preceding composer.json file to our Git repository, we can go back to Packagist and proceed with clicking the Check button, which should result in a screen similar to the following screenshot:

Finally, when we click the Submit button, a screen similar to the following screenshot should appear:

Our package is now added to Packagist, and running the following command on console will install it to into the project:

composer require foggyline/catalogbundle:dev-master

Similarly, we can just add the proper entry to the existing project's composer.json file, as shown in the following code block:

{
"require": {
"foggyline/catalogbundle": "dev-master"
    },
}

Now that we know how to slice out the application across several Git repositories and Composer packages, we need to do the same for the remaining modules within the src/Foggyline/ directory, as only those modules will be registered as the Composer packages.

During the sales module development, we noticed that it depends on several other modules, such as catalog and customer. We can use the require attribute of the composer.json file to outline this dependency.

Once all of the Git repositories for the src/Foggyline/ modules are updated with the proper composer.json definitions, we can go back to our core application repository and update the require attribute in its composer.json file, as follows:

{
"require": {
// ...
"foggyline/catalogbundle": "dev-master"
"foggyline/customerbundle": "dev-master"
"foggyline/paymentbundle": "dev-master"
"foggyline/salesbundle": "dev-master"
"foggyline/shipmentbundle": "dev-master"
        // ...
    },
}

The difference between using submodules and packages might not be that obvious at this point. However, packages, unlike submodules, allow versioning. Though all of our packages are pulled in from dev-master, we could have easily targeted specific versions of packages, if any.