CODEWITHSUNDEEP
phplaravelgitgithubcomposer-php
jrewing
jrewing

Reputation: 155

prevent Composer update to reinstall

I have a Laravel project with some dependencies. One of those dependencies is our own package. I need to do work on that package. The setup is that I symlink our package to a git repository.

vendor/acme/ourpackage -> ~/ourpackagerepo

I make changes in the repository, commit and then run Composer update in the parent to get an updated composer.lock. This used to work fine. But after we moved from Gitlab to Github, composer update acme/ourpackage does:

And thus overwritng the symlink! Then I have to delete the folder and create a new symlink to keep working. That is a hassle, mostly because PHPStorm needs to re-index.

Snippets from composer.json:

"repositories": [{
  "type": "vcs",
  "url": "[email protected]:acme/package.git"


"config": {
    "preferred-install": "dist",
    "platform": {
        "php": "7.0.12"
    },
    "use-github-api": false

Any ideas on how to make composer only update, or leave tha files alone and only update composer.lock?

Upvotes: 2

Views: 766

Answers (1)

Jeremy Harris
Jeremy Harris

Reputation: 24549

I think you have a couple options here:

1. Composer Repository Paths

As pointed out by @Loek, you can use a path repository. This exists to address scenarios that do not typically fall under a VCS (Version Control System such as Git) or as a file artifact. Per the documentation, you use it like this:

{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/my-package",
            "options": {
                "symlink": true
            }
        }
    ],
    "require": {
        "my/package": "*"
    }
}

The most important part to pay attention to is this:

The local package will be symlinked if possible, in which case the output in the console will read Symlinking from ../../packages/my-package. If symlinking is not possible the package will be copied. In that case, the console will output Mirrored from ../../packages/my-package.

Instead of default fallback strategy you can force to use symlink with "symlink": true or mirroring with "symlink": false option. Forcing mirroring can be useful when deploying or generating package from a monolithic repository.

This option makes the most sense to me and is what I would personally go with.

2. Multiple Composer Configs w/ Environment Variables

Another option is to use the COMPOSER environment variable as described here. This will allow you to load a different composer.json file than the default named one. So you might have two files and depending on what you set the environment variable to, it will load the appropriate one and create a matching lock file:

  • composer.json
  • composer-dev.json

Ok, so why in the world would you want to do that? Well due to the way you are trying to work on your package locally (with an active symlink), but don't want that to occur in production, this could potentially work if the first option doesn't.

I should note that your goal should always be to have a single config that works the same across environments (i.e. local, staging, production). I understand that you want to see local changes to your repository immediately in your app and going through the process of commit/push/pull for each change is ridiculous.

Additional Reading/Resources:

Upvotes: 2

Related Questions