niran's avatar
Level 8

Always something breaking when using Laravel * Dependency Hell *

when we started using Laravel we used Laravel 5.8, but the package was named dev-master at the time that is was available. Now, we still use that version because ... just like any project they get larger and larger with time.

Sometimes we want to add a new library and then something like dependency issue comes up and then we cannot use it because that dependency has changed to another version which breaks Laravel 5.8.

I have once again ran into the problem where our composer.json cannot be rebuilt because laravel changed the version tag to something else and dropped something that it once used.

It seems like they just drop stuff and don't look back. I feel this is a bad approach.

We should always be able to rebuild a project from the composer.json file but we cannot. It seems that there are too many inconsistencies to the point where composer won't even find the correct package and leaves you with a broken project. Even I went back to a previous version and use the previous vendor folder and get a vendor must merge, and I don't know what that means because I removed the vendor folder and then remove the old composer.json and composer.lock file and download the version that worked from github and then place them back and git cannot use it even though it is correct.

Also Laravel changed their tags from what they used to be and thus make the project not buildable anymore.

Where do I go from here?

Any suggestions?

0 likes
6 replies
Talinon's avatar

@niran

when we started using Laravel we used Laravel 5.8, but the package was named dev-master

This is the source of your self-inflicted issues. You shouldn't require dev-master because every time you install/update via composer, you're going to be pulling in all the latest commits.

Laravel is not to blame here.. if you're using Laravel 5.8, then you should require 5.8.*, then you won't end up breaking your application and avoiding dependency hell.

I'd pick a stable tagged version of Laravel, and work at fixing all your dependencies from there. Then the framework will only update when you specifically bump your version number in composer.json.

Otherwise, if you want to lock your framework at your current dev-master commit, you could require the specific commit hash....

Laravel/Laravel:dev-master#3d7a5075e7db93a7df89c983c95d9016f448d3f9

niran's avatar
Level 8

Thanks for the Reply Talinon, but this was back when 5.8 was all that there was and it was named dev-master. Back then, quite a few years ago, we were not so knowledgeable about how composer worked and about dependency management. Once you use an application/library for some time, you don't always go and see if the library is still available or installable again. Many packages still have dev-master as dependencies but are not in the main composer.json file but in another package's composer.json. Therein lies another problem. There are often cases where the packages start out as dev-master and later get renamed or tagged as some version that are then not compatible with other dependencies that still use for example (laravel's current dev-master).

Talinon's avatar

@niran Laravel 5.8 was released on Feb 2019, so it wasn't "a few years" ago. I've been using the framework for long before 5.8, so I don't know what you're talking about.

In the 5.8 documentation it shows installing using a version constraint:

composer create-project --prefer-dist laravel/laravel blog "5.8.*"

Or if you used the Laravel installer, it would have entered it for you.

So, I don't understand what you mean by saying that dev-master was "all there was".. can you explain further?

I can appreciate the notion that you didn't understand composer as much back then, we all start off somewhere and need to learn, but again, it's no fault of Laravel's that you required the dev-master branch.

Regardless of HOW you did this, I've explained how you need to resolve it. Change your composer.json to require a non-breaking version range, such as ^8.0 (if you want to be running on the latest) and then work out the conflicts one at a time until you've satisfied all errors.

Another option might be to look into Laravel Shift. I've never used it, but I've heard a lot of developers have. Maybe they can sort out the mess.

1 like
Snapey's avatar

You need to focus on upgrading your project occasionally.

If you need help, use Laravel Shift https://laravelshift.com/

The problem is of your making, you just need to get your head down and fix it.

1 like
niran's avatar
Level 8

HI @snapey If I get the Shift CI + Upgrade Plan does that mean I can shift all, one by one from 5.8 to 9.x ? Is that plan part of this or is their a price for every shift?

jlrdw's avatar

To add, actually going from a 5.8 to an 8 version is not too big of a leap. The various upgrade guides will show you exactly what needs to be done.

But I do agree if you plan on keeping up to date perhaps update and upgrade every few months.

I've never tried that laravel shift, but really updating and upgrading is fairly easy once you get a accustomed to it.

1 like

Please or to participate in this conversation.