PHPackages                             gossi/composer-localdev-plugin - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. gossi/composer-localdev-plugin

ActiveComposer-plugin[Utility & Helpers](/categories/utility)

gossi/composer-localdev-plugin
==============================

Composer Plugin for local development

v0.1-alpha4(8y ago)333.3k4[5 issues](https://github.com/gossi/composer-localdev-plugin/issues)MITPHPPHP >=5.3CI failing

Since Aug 18Pushed 7y ago5 watchersCompare

[ Source](https://github.com/gossi/composer-localdev-plugin)[ Packagist](https://packagist.org/packages/gossi/composer-localdev-plugin)[ RSS](/packages/gossi-composer-localdev-plugin/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (4)Dependencies (2)Versions (5)Used By (0)

Composer local Development Plugin
=================================

[](#composer-local-development-plugin)

A composer plugin that assists you with local dependencies.

Imagine the following: You are developing two packages, A and B. Package A depends on B. In your normal workflow you would push changes you did in package B to github. .... Then wait.... until changes are pushed to packagist and caches are refreshed. Now you can run `composer update` in package A to get all the changes you did in package B. That's very ineffective, not only do you need to to push changes most importantly you need to wait for a change that is just a directory away. Here is a solution.

Installation
------------

[](#installation)

At best this plugin is installed globally, so go ahead:

```
$ composer global require 'gossi/composer-localdev-plugin=dev-master'
$ composer global update

```

Usage
-----

[](#usage)

The priority in this plugin lies in the truth that you shouldn't change your packages code, it should just work as expected when pushed to github and others want to consume it. You only describe your local development to composer and the rest is handled by this plugin. Open '~/.composer/config.json' and add the `localdev` property to the root node:

```
{
    "config": {
        "localdev": {
            "": ["/path/to/your/packages"],
            "sümfony": "/path/to/sümfony",
			"my/package": "/path/to/my/package"
        }
    }
}

```

As you can see, you can define three types of folder types:

1. Global path: The plugin will look for vendor/package packages in these directories. E.g. if you are looking for `my/pkg` it will look for it in `/path/to/your/packages/my/pkg/`.
2. Vendor path: You can give a path for all packages of a certain vendor. E.g. if you are looking for `sümfony/finda` it will look for it in `/path/to/sümfony/finda/`.
3. Package path: Of course explicitly say where a specific package is located. E.g. the lookup for `my/package` will find it at `/path/to/my/package/`.

For global and vendor packages you can give multiple paths by defining them as an array (see the difference between global and vendors paths in the example above - both are accepted).

### Run update/install

[](#run-updateinstall)

The neat idea is, you don't need to change your workflow at all. If you now run `composer install` or `composer update` in one of your packages, those packages that are available locally (described in the global composer config.json) will be symlinked to their original location. You will see something like the notice.

```
=> Symlinked phootwork/lang from /path/to/phootwork/lang

```

Pitfalls
--------

[](#pitfalls)

At the moment, every package that can be found locally is symlinked no matter what. There must be something to control this, because sometimes you just want your package from packagist in the desired version number. Make your suggestions under [Issue #3](https://github.com/gossi/composer-localdev-plugin/issues/3).

Issues
------

[](#issues)

There are still some issues, that haven't been solved:

1. Dealing with custom installers: You may have custom installers, that change the installation destination of your package. Normally, the localdev plugin will just wrap them and both work as expected, yet there is a catch. These custom installers (composer plugins as this one) will be installed during the first installation of that required package. They will be unnoticed to the localdev plugin in the first run, so only the custom installer will work. At the moment, you need to run `composer update` one more time to make them both work (See [\#1](https://github.com/gossi/composer-localdev-plugin/issues/1)).
2. "Ignore Discard Changes": I run across this issue, yet I don't remember what caused this one. I just keep it here as an reminder, there is something. If you run across this, please open an issue.

References
----------

[](#references)

- [Composer Development with local Dependencies](http://gos.si/blog/composer-development-with-local-dependencies)
- [Issue #4011 @ composer repository](https://github.com/composer/composer/issues/4011)
- [Plugin Development (composer-dev@googlegroups)](https://groups.google.com/forum/#!topic/composer-dev/u-jKVnuxg2M)

Contribute
----------

[](#contribute)

Contributions are welcome, at best open an issue or add a comment to and existing one get the discussion going.

###  Health Score

29

—

LowBetter than 60% of packages

Maintenance17

Infrequent updates — may be unmaintained

Popularity29

Limited adoption so far

Community13

Small or concentrated contributor base

Maturity47

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 97.1% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~227 days

Total

4

Last Release

3235d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/0b1ca3beb32834f0f6a4b66d7a695ecc01397aa92e9a97bd0ba5dd8aa14e0c6e?d=identicon)[gossi](/maintainers/gossi)

---

Top Contributors

[![gossi](https://avatars.githubusercontent.com/u/283700?v=4)](https://github.com/gossi "gossi (34 commits)")[![zBart](https://avatars.githubusercontent.com/u/3715094?v=4)](https://github.com/zBart "zBart (1 commits)")

---

Tags

composercomposer-developmentcomposer-pluginpackagistworkflowcomposerdevelopmentlocal

### Embed Badge

![Health badge](/badges/gossi-composer-localdev-plugin/health.svg)

```
[![Health](https://phpackages.com/badges/gossi-composer-localdev-plugin/health.svg)](https://phpackages.com/packages/gossi-composer-localdev-plugin)
```

###  Alternatives

[ergebnis/composer-normalize

Provides a composer plugin for normalizing composer.json.

1.1k37.3M2.1k](/packages/ergebnis-composer-normalize)[franzl/studio

Develop your Composer libraries with style

1.1k634.5k15](/packages/franzl-studio)[bamarni/composer-bin-plugin

No conflicts for your bin dependencies

52722.0M855](/packages/bamarni-composer-bin-plugin)[pyrech/composer-changelogs

Display changelogs after each composer update

5904.0M25](/packages/pyrech-composer-changelogs)[helhum/dotenv-connector

Makes it possible to set environment variables for composer projects.

1594.6M33](/packages/helhum-dotenv-connector)[mnsami/composer-custom-directory-installer

A composer plugin, to help install packages of different types in custom paths.

1395.0M52](/packages/mnsami-composer-custom-directory-installer)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)