7

Problem

Sometimes composer-loaded dependencies are buggy or are missing something you need.

Question(s)

1.) Is it in general allowed to touch/edit anything that composer loaded ?

2.) If yes, then how to prevent these edit from being overwritten / generating conflicts with the next update

3.) If no, then what the way-to-go when edits of composer-loaded dependencies are needed ?

Community
  • 1
  • 1
Sliq
  • 15,937
  • 27
  • 110
  • 143

1 Answers1

9

  1. The simple answer is no.

  2. You can edit the files, but the changes are not permanent.

  3. You have to find a way to get the bug fixed. Available methods are:

    1. report the bug upstream, possibly with a suggested fix (patch or pull request), and wait for it to be included in a new version
    2. clone the original software, fix the bug there, and point to your cloned repository with your composer.json during the time for a) to happen. You might have to alias the dev-master branch (or whatever branch you used to fix the bug) as the next version to satisfy all dependencies.
    3. If the original project is unmaintained, you can think about re-publishing it under a new name, with the bug fixed, and stating in the composer.json that this new software replaces the old one. Please see my answer here for details.
    4. You could also switch to a different software that has less bugs.
    5. You could also try to patch the bug by extending the buggy class in your own codebase, or work around it in other means.
Community
  • 1
  • 1
Sven
  • 69,403
  • 10
  • 107
  • 109
  • Sorry for bringing up an old question, but re: 1. what if it is a library you maintain? Is it best to edit that in its own checkout and do a composer update in the project that uses it? I noticed that the reference in the composer.json gets out of sync if you edit/push from vendor/*. However, a composer update refreshes the .lock file, so all is well then. – Wouter Thielen Jun 29 '15 at 05:24
  • If you don't edit and push in place, but from a different location, your library would have to be updated where it is used, and this wouldn't even result in a conflict in the lock file. Note that the highly preferred way to get new versions out is by tagging them. Editing stuff inside the vendor folder, even though it's possible, has these drawbacks that you have to deal with conflicts and take care to not involuntarily overwrite your changes. I'd try to avoid it. A good library should be developed on it's own, without the need to be integrated somewhere, but it might be required sometimes. – Sven Jun 29 '15 at 12:42
  • Hi Sven, I like your 5th solution. Just found a project with an obsolete dependency and a 6 months old pull request still not merged. I extended the class and just replaced the dependency with a maintained one. 6 lines of code and no need to worry about anything broken by a composer update. Thanks. – Emmanuel BRUNO Nov 28 '19 at 16:24