PHPackages piwi/composer-symlinker - 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. piwi/composer-symlinker ActiveComposer-plugin[Utility & Helpers](/categories/utility) piwi/composer-symlinker ======================= A composer plugin to install packages as local symbolic links v1.0.0(11y ago)181.1k6PHP Since Mar 15Pushed 11y ago2 watchersCompare [ Source](https://github.com/piwi/composer-symlinker)[ Packagist](https://packagist.org/packages/piwi/composer-symlinker)[ RSS](/packages/piwi-composer-symlinker/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependencies (2)Versions (2)Used By (0) Composer symlinker ================== [](#composer-symlinker) A [Composer](http://getcomposer.org/) plugin to install packages as local symbolic links. This plugin is a *temporary* implementation of using symbolic links to local packages as dependencies to allow a parallel work process. For a descriptive (and commented) problematic, see [composer/composer#1299](https://github.com/composer/composer/issues/1299). Usage ----- [](#usage) To use it, just add it as a dependency in your `composer.json`: ``` "piwi/composer-symlinker": "dev-master" ``` You must define concerned local paths or packages as *extra* config entries: - `local-dirs`: a list of local paths to scan while searching a local version of a package ; the final package path will be completed with `vendor/package` ; - `local-packages`: an array of `vendor/package => local_path` items ; - `local-vendors`: a list of vendors to restrict local scanning. ``` "extra": { "local-dirs": [ "/my/absolute/local/path1", "/my/absolute/local/path2" ], "local-vendors": [ "vendor1", "vendor2" ], "local-packages": { "vendor/package1": "/my/absolute/path/to/vendor/package1", "vendor/package2": "/my/absolute/path/to/vendor/package2" } } ``` Windows users warning --------------------- [](#windows-users-warning) The plugin uses the internal [`symlink()`](http://php.net/symlink) PHP function. See *Windows* restrictions on the manual. Quick tutorial -------------- [](#quick-tutorial) Let's say we want to work on a project named `MyProject` base on three dependencies: `MyPackage1` and `MyPackage2` which are some of our packages, and a third-party `ExternalPackage` which is not. Let's say our localhost architecture is the following: ``` [DOCUMENT_ROOT] | |projects/ |-------- MyVendor/ |----------------- MyPackage1/ // this is a clone of MyVendor/MyPackage1 | |MyPackage2/ // this is a clone of MyVendor/MyPackage2 | |MyProject/ // this is the project we currently work on // which depends on other three packages ``` Note: `MyVendor/MyPackage1` and `MyVendor\MyPackage2` must exist in some composer repository already before they can be considered by composer to be installed or symlinked. Typically, packages will already be accessible via Packagist. But if they are local only (no already configured repository) then a local one will need to be added to your composer.json. It might look like this: ``` "repositories": [ { "type":"vcs", "url":"/path/to/DOCUMENT_ROOT/projects/MyVendor/MyPackage1" } ] ``` As we want to work on both *MyProject* and its dependencies *MyPackageX*, we would usually first install our dependencies with Composer (as hard copies), to let it create a valid `autoload.php`, then we would manually replace these hard copies by local symbolic links to our clones of `MyPackage1` and `MyPackage2` ... Well, the plugin can do this for us, as long as we well-configure it and forces Composer to use it when installing our dependencies. The common way to force Composer to use the plugin when installing a dependency should be to include it in its `require` statement. In our case, this is not relevant as we only want to use it to build our local environment (it must not be a requirement for other users). A good way to do so is to create a "development-only" composer's configuration file for our project to let us install local dependencies with the plugin in our environment but let final users have a "real-life" behavior (the default one). Our "development-only" `composer.json` could be: ``` "require": { "piwi/composer-symlinker": "1.*" }, "require-dev": { "MyVendor/MyPackage1": "dev-master", "MyVendor/MyPackage2": "dev-master", "OtherVendor/ExternalPackage": "dev-master" }, "extra": { "local-dirs": "/path/to/DOCUMENT_ROOT/projects/", "local-packages": { "MyVendor/MyPackage2": "/path/to/DOCUMENT_ROOT/MyPackage2" } } ``` This way, we may first run: ``` $ composer install --no-dev ``` to install the plugin, then: ``` $ composer update ``` will use it to install all packages. Our final `vendor` directory should be something like: ``` [vendor] | |MyVendor/ |--------- MyPackage1 => /path/to/DOCUMENT_ROOT/projects/MyVendor/MyPackage1 (symlink) |--------- MyPackage2 => /path/to/DOCUMENT_ROOT/MyPackage2 (symlink) | |OtherVendor/ |----------- ExternalPackage/ (hard copy) ``` and our autoloader will be still valid. ### Health Score 33 — LowBetter than 74% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity25 Limited adoption so far Community13 Small or concentrated contributor base Maturity63 Established project with proven stability Bus Factor1 Top contributor holds 92.3% 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 Unknown Total 1 Last Release 4073d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/bdcad88f9577d45da703864395c687480896a757e90978502b600d9dd588c247?d=identicon)[picas](/maintainers/picas) --- Top Contributors [![e-picas](https://avatars.githubusercontent.com/u/1021199?v=4)](https://github.com/e-picas "e-picas (12 commits)")[![ralphschindler](https://avatars.githubusercontent.com/u/76674?v=4)](https://github.com/ralphschindler "ralphschindler (1 commits)") ### Embed Badge ![Health badge](/badges/piwi-composer-symlinker/health.svg) ``` [![Health](https://phpackages.com/badges/piwi-composer-symlinker/health.svg)](https://phpackages.com/packages/piwi-composer-symlinker) ``` ### Alternatives [vaimo/composer-patches Applies a patch from a local or remote file to any package that is part of a given composer project. Patches can be defined both on project and on package level. Optional support for patch versioning, sequencing, custom patch applier configuration and patch command for testing/troubleshooting added patches. 2994.3M14](/packages/vaimo-composer-patches)[mglaman/composer-drupal-lenient 1317.4M15](/packages/mglaman-composer-drupal-lenient)[drupal/core-composer-scaffold A flexible Composer project scaffold builder. 5341.9M440](/packages/drupal-core-composer-scaffold)[drupal/core-project-message Adds a message after Composer installation. 2122.6M172](/packages/drupal-core-project-message)[olvlvl/composer-attribute-collector A convenient and near zero-cost way to retrieve targets of PHP 8 attributes 184108.8k8](/packages/olvlvl-composer-attribute-collector)[lullabot/drainpipe An automated build tool to allow projects to have a set standardized operations scripts. 41716.4k2](/packages/lullabot-drainpipe) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)