Here's the question: do you want to implement and maintain what someone has already done and spent countless hours developing? and has multiple users finding/fixing bugs, offering improvements, etc? Using any package comes at a risk, and composer update should always be something to be weary of, and always test locally first, but the benefit is very high for low risk... depending on the package of course... you have to weight the cost/benefit of either approach.

Fork it and maintain it yourself if it is inactive. If you choose packages of good quality that should be still a lot faster as inventing the wheel over and over again...

I agree with the previous comments. When you look at the sheer amount of functionality offered by packages, it's hard to imagine writing all of that code yourself (and maintaining it!).

The more packages you use the harder it will be to stay on the 'bleeding edge' (in terms of keeping your app updated). However, as your application grows, it will become harder and harder to keep updating anyways.

Thanks for the feedback.

Maybe a paid marketplace would be nice for those that want to pay for ensuring updates, especially for business use.

Yeah that's an idea, but TBH even when you pay for packages you can't always be sure they stay updated in a timely manner.

If you are that worried about it then just be careful which packages you use. Only select ones that are backed by a company (like Symphony components), or have tons of followers (Illuminate/Aura components), or are created by a prominent member of the PHP community with a good track record, or are created by a coalition of community members who aim to work together to prevent these issues (i.e. https://github.com/thephpleague).

yeah, i guess it just serves to be very careful about what is added through composer as it's not as rosy as it may seem down the line.