Composer - using a local repository

Question

I am a Composer beginner and I am trying to make one project dependent of another one, while both project only exist on my local machine.

The composer.json in my library project (ProjectA) is:

{
    "name" : "project/util",
    "type" : "library"
}

I initialized git in the base folder of this project.

My composer.json in the project depending on the first one (ProjectB):

{
    "repositories": [
        {
            "name" : "util", 
            "type" : "git",
            "url" : "/d/workspaces/util"
        }   
    ],

    "require": {
        "project/util" : "*"
    },
}

When I run composer install from ProjectB, I get the following error:

[RuntimeException]
Failed to clone , could not read packages from it
fatal: repository '' does not exist

I asume something is wrong with the url of the repository, but I am not sure what else to write there.

Answer 1

Autoload local package using composer (without going to packagist every time you change).

There are many ways to do so, I will be covering 2 of them:

In all cases we have 2 main parties:
- the local package (the code that we do not want to publish on packagist to be able to autoload it in our project composer).
- the main project (the code base that needs to use the local package code, can be another package and or any project).

---

Method 1: (direct namespace)

Open the main project composer.json file and autoload the local package namespaces using any method (PSR-4, PSR-0, ...).

example:

if in the composer.json of the local package we have:

  "autoload": {
    "psr-4": {
      “Local\\Pack\\": "library"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Local\\Pack\\Tests\\": "tests"
    }
  },

then in the composer.json of the main project we should have:

  "autoload": {
    "psr-4": {
      "Mahmoudz\\Project\\": "src",
      "Local\\Pack\\": "../path/to/local/pack/library”                   << referencing the other local package
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Mahmoudz\\Project\\Tests\\": "tests"
    }
  },

Advantages:
- you don’t touche the vendor directory (running composer update by mistake will not override your local changes)
- you don’t need your package to be on packagist to use it
- you work in one place (the local package) and the changes are automatically loaded in the main project
Disadvantages:
- you cannot publish the composer.json on production (needs editing before publishing to require the real package)

Method 2: (local repository)

Download the local package from a local repository.

local package:
1. initialize git in the package (even if you don’t want to use it - no need to commit anything)
2. add composer.json file. In the file make sure you have the following:

"name": "vendor-name/package-name",  

"autoload": { …   // use whichever method you prefer, but make sure it’s being loaded correctly

"minimum-stability": "dev"  

3. composer dump-autoload

main project:
1. edit your composer.json to contain the following:

  "repositories": [
    {
      "type": "vcs",
      "url": "/full/path/to/the/local/package/package-name"
    }
  ],
  "require": {
    "vendor-name/package-name": "dev-master"
  },

2. composer update vendor-name/package-name
3. now check your vendor directory you should see the vendor-name/package- name

NOTE: whenever you make change in the local package (not the vendor) you need to git commit then you can composer update the main project, it will get the latest copy of the repo to the main project vendor directory.

Advantage:
- you don’t touch the vendor directory (running composer update by mistake will not override your local changes) - you don’t need your package to be on packagist to use it
Disadvantage:
- you have to keep committing your changes (in the local package) and then running composer update in the main project
- you cannot publish the composer.json on production (needs editing before publishing to require the real package)

Answer 2

I think you've just got the syntax wrong. The type should just be VCS, and then composer figures out what type of VCS it is.

So in your project B, the entry for repositories should be:

"repositories": [
    {
        "type": "vcs",
        "url" : "/d/workspaces/util"
    }
],

You don't need to name what library is available in /d/workspaces/util. Composer will scan the composer.json file in that directory and know what project name is available there, and use the project from that directory in preference to a version listed on packagist or other repository.

Answer 3

The easiest way is to use type=path https://getcomposer.org/doc/05-repositories.md#path

{
    "repositories": [
        {
            "type" : "path",
            "url" : "/d/workspaces/util"
        }   
    ],
    "require": {
        "project/util" : "*"
    },
}

Answer 4

I found this tutorial really useful: https://johannespichler.com/developing-composer-packages-locally/ when I was facing issues with local package production

Note the symlink condition allowing the vendor folder to be a symlink which then means you no longer need to composer update each time you want to see change

"options": {
        "symlink": true
      }

Answer 5

In addition to Danack's solution: Changing the path from /d/ to d:/ worked for me.

Like this:

"repositories": [
    {
        "type": "vcs",
        "url" : "d:/workspaces/util"
    }
],

Answer 6

NOTE: This answer assumes that you have something like a Package Registry or GIT repository where you can retrieve the releases of your package. If you do not yet have this. https://getcomposer.org/doc/05-repositories.md

Composer enables us to autoload a local development package without contaminating the composer.lock file. When Composer finds a conflict between two or more packages it wil autoload only one of these packages.

You can use the autoload-dev to autoload a specific folder for development. (https://getcomposer.org/doc/04-schema.md#autoload-dev)

The autoload-dev (and autoload) settings do not touch the composer.lock file

In your projects composer.json file:

"repositories": {
    "99999999": {
        "type": "composer",
        "url": "https://gitlab.com/api/v4/group/99999999/-/packages/composer/packages.json"
    }
}
"require": {
    "a-vendor-name/test-package": "1.0.*"
}, 
"autoload-dev": {
    "classmap": [
        "./../../packages/a-vendor-name/test-package"
    ],
    "exclude-from-classmap": [
        "vendor/a-vendor-name/test-package"
    ]
}

In this example the packages directory lives outside the project root and contains its own package GIT repositories.

autoload-dev because we only want this folder to load when we are developing. (https://getcomposer.org/doc/04-schema.md#autoload-dev)

classmap to load the packages from a local directory. (https://getcomposer.org/doc/04-schema.md#classmap)

exclude-from-classmap to disable loading the package within the vendor directory. Will also suppress the warning about multiple classes with the same namespace. (https://getcomposer.org/doc/04-schema.md#exclude-files-from-classmaps)

Running DEVELOPMENT (default behaviour):

composer update a-vendor-name/test-package // or any other composer command 

Your package will still be downloaded from your Package Registry. This downloaded package is not only ignored in you applications code, its also possible to update it according to the project composer.json file. Which in turn will update the composer.lock file, the right way.

Running DTAP / PRODUCTION by using the --no-dev flag:

composer update a-vendor-name/test-package --no-dev // or any other composer command 

Answer 7

In addition to @Glen Solsberry's solutions, if you're running in a docker container like me, you can add a volume to your docker-compose.yml file like:

services:
  theservicename:
    ...
    volumes:
      - ../:/var/www
      - /path/to/src/package:/var/www/vendor/path/to/src/package
    ...

When you make changes locally they will reflect in the container.