What's the difference between general PHP & Laravel specific packages?

I'm not very knowledgable and I'm sure that a lot of people can answer way better than me but I'm going to give you an example that may apply.

I have to deal with an application API to schedule meetings/trainings. There's no Laravel specific package for it and I have to use an obscure PHP package that's not really mantained anymore even though it's code is good to my eyes (programming to interfaces, kinda close to SOLID etc).

However, the package uses straight CURL and has a lot of lines of code to handle requests, headers etc. If I were to implement it on Laravel I would use Guzzle to give you an example and maybe shorten the amount of code by abstracting the CURL part.

That's what I can think of, I don't know if its helpful or even if it's correct but I guess that Laravel implementations use Laravel native code or its direct dependencies.

Hope it helps

Ok, but usually when you use some package, you are mostly interested in the method calls, how easy it is to use, and maybe performance, not the code behind it.

Yes, that's right. In my case I need to redo some stuff because the package is done for a service I don't really need so I need to change stuff in order to make it work for the service I do need, the methods are very similar so if I have to refactor I would consider the Laravel specifics because I will be using it there.

However, as I told you, I'm not really the best person to answer this, I was trying to show one case in which it would make sense to use a Laravel specific package. Sorry if it's completely useless.

I'm gonna add my comments and opinions but like @erozas said, it's just a personal opinion.

I see Laravel specific packages as just being coded to a "laravel style" and the ability to be required by composer with very little trouble.

Compared to say some "php library" which does not come with the "ease of use" that a laravel package offers. However, you can still put those files into a directory like "lib" possibly namespace them and then add a few require lines with a serviceprovider. After you have done that work you basically have a package minus a faced and autoloading. In a way view composer and macros fit this category of usage. Regarding a generic package, you still can use composer but you still might need to do some coding to integrate it and will have to keep an eye on version compatibility. But! a generic composer package doesn't depend on a laravel version, it is your connecting code that does.

The benefits are obviously with a laravel specific package since it is almost plug and play. So, I will normally choose a laravel package even if it is not as powerful or limited compared to a generic package. ( I'm lazy ;) )

The main aspect is, a Laravel package is plug-and-play, you just install it with composer, add the Alias (if needed) and the Service Provider (if there is one) and you are ready to go. With a general package you can still add the Alias (so you can use MyClass instead of MyName\MyPackage\MyClass), but you would need to create the Service Provider, make any configurations file and make the library use that config and things like that. But there are packages that don't need much configuration, so it's pretty much the same.

A Laravel specific package may also use things that are already on Laravel, eg: Queue or Mail, so you if you already have Mail configured, it will just work.

Erozas (@erozas) raised a good point, sometimes the package are no longer supported and you need to change it to fix bugs or add features, or maybe it is supported but you want to make a pull request for those things. If it's a Laravel package, you will most likely "feel at home" while changing it.

OK, thanks for the answers :)

It looks like the main difference is easier configuration. Anything else?