Occasionally I'll find a package that needs some tweaking to work, and rarely I find a package that is exactly what I need out of the box. What I tend to do it decide whether it would take about the same amount of time to tweak the package, or tweak my logic to work with the package vs. just creating it from scratch myself.

If you found a particular package didn't quite suit your needs, and ended up writing the functionality yourself, however, you could release that as a package, as there is likely another person with the same problem as you.

Thank you so much for your reply.

Would you ever consider creating the core part of your functionality by depending upon a package, would it be advisable to do that, Before i start actually writing the code for my project, I just want to sink deep into me that, that is a good way to go. Only reservation I have is, I won't have control over the code and in the long run i might spend a long time trying to figure out of fix something. I guess I am a little confused as I have just started using laravel and I want to get the best out of it.

Thank you once again.... I will definitely release that as a package if it ended of writing one....

If I was relying on a package for my a core piece of my functionality, I would run the PHPUnit tests myself, and be very careful with upgrading the package anytime a new version came out. This is something you want to do with any package you utilize, but especially so if your application really depends on it.

If it helps you better sleep at night, write it yourself, and maybe use the package as a guide. But in general, and especially if it is a widely-used package, it is fairly safe to use. You can always, of course, go through the code yourself to ensure it meets your standards.

Thank you very much for your replies.

Just make sure you follow the progress of the package for any breaking changes. If you are missing something, just ask the creator what they think about it, perhaps they have ideas to implement it, do it in a better way or even add the functionality to the package. And it is all open source, so you can just fork it, submit some patches or continue on your own..

Laravel is still being developed very actively, so a lot of packages aren't 'finished' yet, and some will never be (deprecated etc). But Laravel is not a CMS with plugins, it's just a framework with packages as more building blocks.

Thank you barryvdh, I really appreciate it.

I have just started working on the project, so I am trying to weigh what gives me more benefit and which will be faster to do. As soon as I saw I did not have the major part that needed to be implemented, I was trying to decide on should I dig deeper into the package and start implementing the functionality I need or should I start fresh. So i just wanted to put a question out there to all the people who have already been to the point where i am right now.

Thank you so much....

I would say too much dependency is not a good thing. I try to build everything from scratch and have a few underlying services that I really have to have. Some packages that old Joe builds today might be depreciated tomorrow because not that many people are following or maintaining it. I would focus on packages that have a big following and if you can contribute to them. For example, I am building an app that uses SMS currently and at first there were only a few repositories for what I needed. One of them was not even maintained that well and did not work so I decided to just grab the API from the SMS Service and convert it to the Laravel structure.

Thanks for you reply swgj19