5

I hope my question is not too vague, but can't get a proper answer by searching.

I have the following situation; We are working on a project and have certain dependencies installed through Composer. One of these dependencies is quite outdated and requires some fixes and additions. I have forked this repo on GitHub and added it to Packagist.

To work on the code, I need it running in my project and edit from there to see if my changes work, but it is in the vendor folder, where it is installed through composer.

Cloning this project through GitHub directly in the vendor folder won't work, as the autoloader won't be written for it.

What I have done so far is working in the vendor folder, and then copying and pasting my work from there to the GitHub folder and pushing from there, but logistically quite tricky.

How does one work on a composer library that is embedded in a project, in such a way that you can commit your changes from this folder?

Richard
  • 4,341
  • 5
  • 35
  • 55

1 Answers1

6

  1. Change package constraint in composer.json to use branch instead of tagged version - you can use dev-master for master branch or dev-my-branch for my-branch branch. You may also configure branch alias.

    "require": {
    "some-vendor/some-package": "dev-master",
}

  2. Add a repository which points to your fork:

    "repositories": [
    {
        "type": "git",
        "url": "https://github.com/richard/some-package/"
    },
]

  3. Run composer update to install new version from your fork (or composer require "some-vendor/some-package:dev-master" if you don't want to update any other dependencies).

Now you should have sources cloned from your fork in vendor/some-vendor/some-package. You can edit these files and test if changes fits to your app. After you finish your work:

  1. Commit changes in your fork and push them to GitHub.
  2. Go back to root of your app and run composer update or composer require "some-vendor/some-package:dev-master". This will update your composer.lock file to use latest version of your fork. Then commit changes in your lock and push.

Now if someone will clone your project (or just pull changes) it will get new composer.lock pointing to your fork with specified commit hash - composer install should always install the same version of your fork directly from GitHub.

rob006
  • 21,383
  • 5
  • 53
  • 74
  • I think you're missing the main question; how do I get the repo in my project (and have it in the composer.json) so that I can actively work on it and my changes can also be committed to GitHub. Currently I'm copy-pasting file contents from the `vendor` folder, to the separately checked out GitHub project. I know how to get my forked version in through `repositories` in `composer.json` – Richard May 13 '18 at 21:27
  • @Richard This should clone your fork directly to `vendor` directory, so you can edit it from there. – rob006 May 13 '18 at 21:42
  • On the short term, that works, but I need to have the package in `composer.json` so that I can test on the staging server also (and to make sure I don't forget to add it before publishing to production). This solution is not really workable with composer and multiple enviroments.. Is there no better way? – Richard May 13 '18 at 21:44
  • @Richard I'm afraid I don't understand what is the problem. This approach adds your fork package to `composer.json` and saves used version in `composer.lock` so on every environment you will get the same version of forked package. I worked in this way in multiple environments without any problems. Please express your concerns more clearly. – rob006 May 13 '18 at 21:51
  • So the issue is; yes I can clone my repo through composer, but it is just a "checked out" version of the repo. The repo however is not finalised; I'm still working on it and need to be able to edit that code directly and test if it works in my project. When checked out via composer though; the changes I make there aren't tracked by the GitHub app as it isn't a GitHub "folder", but a composer folder. It's a "WIP" folder, but also needs to be in Composer. – Richard May 13 '18 at 21:56
  • @Richard Sorry, but did you at least tried this solution? This creates clone of your fork repository in vendor directory as a dependency, so you can edit it and push changes to GitHub. Then you can update your `composer.lock` to point to a new version your fork. This is both "GitHub folder and composer folder" at the same time. – rob006 May 13 '18 at 22:05
  • No have not, but just as I was typing my previous response, I think I understood what you meant. 1. Checkout the folder from GitHub, 2. remove physical folder 3. run `composer install/update` 4. GitHub thinks the composer folder is the GitHub folder, so you can work on in and track changes. Is this right? – Richard May 13 '18 at 22:10
  • @Richard More or less. Usually `composer require "me/forked-package:dev-master"` should be enough. The only tricky part is to regenerate `composer.lock` in main repo after pushing to forked repo of dependency. – rob006 May 14 '18 at 08:40