Using studio along with a git branch workflow

[RemiCollin]

I guess this issue is more related to the inner workings of composer than a studio issue, but I think it's quite relevant here.

We're using a git branching workflow on a project's package loaded with studio. Problem is, when switching the package to another branch than the 'dev-master' which is required in the main composer.json of the project, composer will drop the studio package in favor of the dev-master branch from the .git remote repository.

In order to use the studio package again, we then have to update the main project composer.json to require the 'dev-feature/branch' instead of the dev-master.

Is there a workaround around that ? If I remember correctly in previous studio version, it was working whatever branch you were using, which was a great workflow IMO.

[buznablaster]

Hi,

I think one solution to this is to add an explicit "version": "dev-master" to your packages composer.json file. That way composer should identify it as the dev-master version and use the workbench package. Although I do not prefer this solution so much as using an explicit "version" in a packages' composer,json is IMHO not recommended.

[franzliedke]

Hi folks, thanks for bringing this up!

I consider this a bug, too - it's clearly unexpected behavior.
Without having given it much thought, our only way to fix this might be to build our own "repository" implementation that we use - it would probably build on top of Composer's path repository implementation, but would always return the current package - whether its branch matches the constraints in composer.json or not. Thoughts?

[RemiCollin]

Well, that would definitely do it for me 👍

[buznablaster]

hmm, having a quick look at ArrayRepository which is extended by PathRepository, https://github.com/composer/composer/blob/master/src/Composer/Repository/ArrayRepository.php
perhaps it would be enough to override
public function findPackage($name, $constraint)

what do you think ?

[franzliedke]

@buznablaster Thanks for looking into this.

I played around a bit and it turns out it's a bit more complicated. When running composer update, Composer loads all packages via the repository's getPackages() method. If the packages returned by that method do not match the constraints checked against by the solver, then we have a problem. Digging further...

[RemiCollin]

Would it be possible to workaround this by hooking the symlink creation to SCRIPTEVENTS::POST_UPDATE_COMMAND , whichever version composer chose to install ?

(edit : i realize after posting this, that this may rise several issues, as not using the composer.json from tha managed package)..

I looked into composer code, and it doesn't look simple to bypass the constraint at all..

[franzliedke]

Not completely sure, but I was afraid already we might have to do that

[franzliedke]

Okay, as hinted previously, my plan here is to have Studio basically ignore the version constraint that you declare in composer.json.

In a perfect future, Studio will then probably display a warning that dependants that don't use Studio (as they shouldn't) will get a different version of the library using the current constraints. Given the big problems with the lockfile (#52), this might mean that we first run a normal composer update (i.e. properly downloading all files from Packagist etc.), before having Studio replace certain packages with symlinks (so that we keep a valid lock file).

Now for the hard part, the implementation...

[Rjs37]

I just came across this issue myself. Knowing that I just need to temporarily change the branch in my main composer.json file is good enough as a short term fix.

Might be worth adding that as a note to the docs in the meanwhile?

[franzliedke]

@Rjs37 Can you post an example of what such a note could look like?

[Rjs37]

I was thinking of something along the lines of the below, probably between the Loading local packages and Kickstarting sections.

Using branches on your package

When using local branches for your package, you will also need to update your composer.json. The branch declared in your composer.json must match the local branch of your package for composer update to work correctly:

"require": {
    "my/world-domination": "dev-feature/branch"
}

[furey]

@Rjs37 Pulling my hair out for ages over that. Cheers!

@franzliedke Thanks for an awesome package. Love your work!

[weitzman]

I second the request to add a note to docs as suggested above #56 (comment)