Preserve aliases information from merged packages

[jiripudil]

fixes #100

[reedy]

You might want to rebase your patch so CI doesn't error :)

[jiripudil]

Good point, rebased onto #189. Should I mark this PR as a draft so that it doesn't get merged accidentally?

[jiripudil]

Also, on a side note, would you appreciate a PR migrating over to Github Actions? To my dismay, waiting for Travis feels like ages recently.

[reedy]

Also, on a side note, would you appreciate a PR migrating over to Github Actions? To my dismay, waiting for Travis feels like ages recently.

Could do.

I was planning on doing the same thing when I got a little bit more time this weekend, as it's not particularly difficult to do :).

Fixing CI (forcing composer 1.x) as I did was only a couple of minute job, so was easily done in the meantime.

[reedy]

Also, on a side note, would you appreciate a PR migrating over to Github Actions? To my dismay, waiting for Travis feels like ages recently.

Started on https://github.com/wikimedia/composer-merge-plugin/tree/githubactions

[jiripudil]

Lovely, thank you! Rebased onto master. The development is suddenly a breeze when you get almost instant feedback from the CI :)

[XedinUnknown]

Hi! Since this seems to have been fixed some time ago, and tests are passing, what is blocking the merge please? I would like to use Composer's resolution for my modules if they declare the same dep as root package. In my case, the module needs to depend on a fix branch of the same dep that is required with a more stable constraint in the root. If the module was a dependency, this would be trivial to solve with inline aliasing. Alas, it does not work. I'm really hoping this PR could fix this.

Also, it would be great if 1.x would receive this fix, as many are still on Composer 1.

[sajphon]

Tested the PR locally and it seems to do exactly what it claims to do and I didnt run into any issues while using it. This should be merged asap.

[XedinUnknown]

This comment seems to imply that the changes of this PR are included in the master branch. If it has, I guess it has been released? What's the version with this change, please? Since it's a rebase and not a merge, this information is not available.

[reedy]

This comment seems to imply that the changes of this PR are included in the master branch. If it has, I guess it has been released? What's the version with this change, please? Since it's a rebase and not a merge, this information is not available.

No it doesn't. It was originally against master before we had GitHub actions. It was rebased onto newer master when we had GitHub actions, so CI actually worked properly.

[sajphon]

@reedy so what seems to be the problem with releasing it ? 🤔

[XedinUnknown]

Any news on this, please?

[sajphon]

@reedy any news ?

edit: How is this still not merged ?

[utrotzek]

I stumbled up on that issue today as well. It would be really nice if the fix can be releases in one of the next versions. I can help with testing if desired ;)

[pradtke]

Since jiripudil:preserve-aliases is a few commits behind master, I made my own branch from wikimedia:master and merged the PR into that, and tested it. It worked as I expected. I'm looking forward to this PR getting merged and released.

[steffendietz]

Stumbled across #100 basically 5 minutes after discovering this plugin and giving it a spin.

Could this be moved forward, please? It's been more than 6 years since the issue was first described and now almost 2 years this seemingly functioning PR is just sitting here.

[HaaseIT]

@reedy any news on this?

[jiripudil]

Wow, glad to see this merged, eventually. Thanks! 🫶