composer.lock require section is not updated

[develop-bvi106]

Hi, i'm using this awesome plugin for our local development.

Let's say i have PROJECT1 using PACKAGE1 via composer link, after having installed new dependencies on PACKAGE1, the composer dump-autoload in PROJECT1 doesnt see new dependencies installed and doesn't autoload new modules.

I've noted that, also after composer update PACKAGE1, the composer.lock require section is not updated using the require section of the local COMPONENT1 but seems it's using the published package dependencies on Packagist, it does update the composer.lock hash but doesn't reflect the required dependencies changes in the parent composer.lock file.

We have many others dependencies in PACKAGE1 composer.json\require (already published on Packagist) that are loaded correctly from the parent project.

Maybe i'm missing something or have messed up with package dependencies, any help would be greatly appreciated!

[ashooner]

We have the same issue. This is really a great tool; but our problem use case is when we change the version of a require entry in a linked package's composer.json file, that local change is not respected by the composer install on the root package. If composer-link is just managing aliases, this makes sense, since composer (apparently) will refer to the package's repository for metadata while resolving the dependency tree.

My thought was to have composer-link dynamically replace the linked package's repository with a local path-based repository, which (again, I assume) would make composer respect the local composer.json file, and its changes. I'm just starting to review it, but it looks like composer link does this, or something like it, already. I'm not at all familiar with Composer's api, so kind of feeling around in the dark.

[SanderSander]

This weekend I should have time to look into this. I think I will be able to create some tests for this, and hopefully resolve the issue afterwards.

[SanderSander]

@develop-bvi106 After reading what the issue exactly is, I think that you mean the following feature: https://github.com/SanderSander/composer-link/issues/18

So let's say we have a project and that project requires package1 that package has a dependencies to package2: 1.0.0

Now we want to link package1 in our project for development in that package, and we update the composer.json file so that the package is upgraded, package2: 2.0.0 as example. In that case when composer install is executed you will see that package2: 1.0.0 is installed and this is currently the expected behavior.

The issues that I linked doesn't have that much information in it, but I wanted to add this as a feature.

I'm think about the following solution: composer link ../my-package --resolve-dependencies that links the local package and then resolves all the dependencies to install those dependencies also, so now it will install package2: 2.0.0 on your development environment without altering your composer.lock file

I already experimented a bit with that feature, but it seemed a bit complex but not impossible, nevertheless I will try to continue with this feature this weekend.

Would this work for you?

[ashooner]

Thanks for the prompt reply! What you describe would meet our requirements, although it would involve re-linking if the package2 version changed in the course of development.

It looks like you have a lot of work into this approach already, but just to brainstorm: last night I started to look at subscribing to pre-install-cmd and pre-update-cmd events, and actually generate dynamic path type repositories, based on linked packages. I think that would allow composer to refer to the local package1 composer.json file directly without additional dependency resolution logic. However, this would mean changing the composer.lock file, which it sounds like you'd prefer to avoid. The lock file is ephemeral in our use case so that wouldn't be an issue.

[SanderSander]

Thanks for the prompt reply! What you describe would meet our requirements, although it would involve re-linking if the package2 version changed in the course of development.

Yes so changes in the dependencies of the linked packages will require a new composer install or re-linking the package, there is simply no way to detect those changes otherwise (maybe there are but way to impact full on the system).

It looks like you have a lot of work into this approach already, but just to brainstorm: last night I started to look at subscribing to pre-install-cmd and pre-update-cmd events, and actually generate dynamic path type repositories, based on linked packages. I think that would allow composer to refer to the local package1 composer.json file directly without additional dependency resolution logic. However, this would mean changing the composer.lock file, which it sounds like you'd prefer to avoid. The lock file is ephemeral in our use case so that wouldn't be an issue.

Yes, because for most projects it's import to commit the lock file and also a good amount of libraries choose to commit their lock file, so this tool is really for development purpose to make easy changes/bugfixes in an included libraries.

In composer you could also define path repositories as described here: https://getcomposer.org/doc/05-repositories.md#path which will symlink you packages into your project and also install all required dependencies, but this requires altering your composer.json file, and after the install your composer.lock will also be changed, and in most cases reverting those files to commit changes

[fbramato]

@SanderSander sounds perfect to us, is exactly what we need for.

Meanwhile we found a workaround: commiting the modified branch with new dependencies on github and modifying composer.json in parent project, did the trick

"repositories": [
        {
            "type": "composer",
            "url": "https://repo.packagist.com/org/",
            "only": [
                "bvi/*"
            ]
        },
        {
            "type": "git",
            "url": "[email protected]:org/framework.git",
            "only": [
                "org/framework"
            ]
        }
    ],

and then reference the package version as: "org/framework": "dev-other-branch",

launching composer update org/framework actually updates correctly the parent project composer.json and .lock and also the composer classes autoload