Sometimes seems to miss packages

[egbertmza]

Hi, I am using apiato as a framework, and it uses your merge plugin. The issue I am having is that when running composer install, it seems to miss packages. Once I delete the composer.lock file and run composer install again it seems to detect and install the missing packages.

the solution probably has 50 or more "containers" that each contain a composer.json file (most of them empty). I get the feeling something goes wrong when its merging...but I cant validate my theory... there are no errors or warnings...

has anyone experienced similar issues ?

I have no idea how to resolve this....

[XedinUnknown]

If you run composer update in the "sub-package" directory, it will use the sub-package's composer.json only, and will create a composer.lock file in that directory. Subsequently running composer update in the main package's root folder seems to ignore changes in sub-packages. To mitigate this, make sure to remove the composer.lock file from the sub-package's directory first. Don't forget to delete the sub-packages's vendor folder that would have been created in that directory too.

Hope this solves your problem.

[XedinUnknown]

Eh... it appears that this is not the cause. I checked again, and it didn't work.

[edersoares]

When you use composer install and you have a composer.lock in your root package, just dependencies in composer.lock are installed and dependencies into sub-package's composer.json are ignored, because Composer don't recalculate the dependencies, it just install what it see into composer.lock.

To install dependencies that exists into sub-package's composer.json and don't exists in root package composer.lock you need to use composer update --lock instead composer install.

https://github.com/wikimedia/composer-merge-plugin#updating-sub-levels-composerjson-files

[XedinUnknown]

Not sure I understand. How about an example?

• Let's say I have my sub-packages in modules.local.
• I have a single package there in modules.local/core.
• core/composer.json declares a dependency on wp-oop/wordpress-interface.
• The root composer.json does not declare a dependency on wp-oop/wordpress-interface.
• I had already run composer update in the root, and it successfully installed wp-oop/wordpress-interface.
• If that package is installed, this means that it should now be in the root composer.lock. I can test that, and it is true.
• When I now run composer install in the root, it installs wp-oop/wordpress-interface. Sounds good to me, but seems to counter what @edersoares says.
• When I now run composer update in the root, it tries to remove wp-oop/wordpress-interface. This is counter-intuitive, and I don't understand how to stop that. It happens no matter how many times I run composer update --lock.

Also, the docs seem to mention that composer update --lock re-calculates the hash. That should mean that I should run composer update --lock to re-calculate the hash, and then composer update to actually install the updated dependencies; please correct me if I'm wrong. Composer docs mention that the --lock flag causes Composer to only update the hash. But when I run it, it seems to attempt to update all dependencies, too.

By the way, you can actually see this example here.

[edersoares]

@XedinUnknown

When I now run composer install in the root, it installs wp-oop/wordpress-interface. Sounds good to me, but seems to counter what @edersoares says.

If you have composer.lock in root project, composer install will install all dependencies within composer.lock and if you have wp-oop/wordpress-interface in composer.lock, it will be installed.

In my case, I don't save composer.lock with subpackages dependencies, for that seems to counter, sorry.

I did here with my project, install and update are installing all dependencies to me.

My root composer.json looks:

    "extra": {
        "merge-plugin": {
            "include": [
                "packages/*/*/composer.json"
            ]
        }
    },

[XedinUnknown]

Ok, now I understand your case, thanks!

I seem to have misunderstood how composer update --lock works. Composer docs say that it will only update the hash in the lockfile, whereas in reality it will check if composer.lock is on par with stuff declared in composer.json. If it is not, it will actually update dependencies. If nothing has changed, it appears to do nothing: the hash will be the same. So, that kinda explains why composer-merge-plugin needs composer update --lock. It also means that we should run composer update --lock instead of composer update.

What doesn't make sense to me now is that when I run composer update it attempts to uninstall those deps that are present in sub-packages but not in the root package. Running composer update --lock shows that there's nothing to install or update, while composer update results in something like this:

Package operations: 0 installs, 0 updates, 66 removals
   - Removing wp-oop/wordpress-interface (dev-task/initial-interfaces)

[Mohammad-Alavi]

I have the same problem as this. I don't understand why this is happening, it doesn't make sense 🤔. Can anyone explain it?