Support Laravel 5.2

[EspadaV8]

Laravel 5.1 deprecated using bindShared and 5.2 removed it completely, because of this a package update to cocur/slugify is needed to at least 1.4. orchestra/testbench 3.0 only supports Laravel 5.0.* so that requires an update as well.

Illuminate\Foundation\Composer has been moved to Illuminate\Support\Composer

[EspadaV8]

The failed test is because of PHP 5.4 which isn't supported by Laravel 5.2 so the change in the Composer class location throws an error.

@cviebrock would you be okay with me updating composer and travis to remove PHP 5.4?

[EspadaV8]

Dropping PHP 5.4 would also mean increasing the minimum Laravel version to 5.1 (which requires PHP 5.5.9 or above).

[EspadaV8]

Actually, it's going to increase Laravel to 5.2 anyway isn't it, because it requires the Composer class in that location. Duh.

[nivv]

@EspadaV8 I saw this commit from another repo:

https://github.com/laracasts/Laravel-5-Generators-Extended/pull/83/files

That would (allegedly, since I haven't tested it) make it work on both 5.1 and 5.2 (including the things you proposed)

[EspadaV8]

That requires use of the global app function. Does this package mind requiring that? It would also be possible to inject the Container class and use that to resolve the Composer class instead of using the global function, which might be a bit nicer.

[nivv]

@EspadaV8 agreed! Lets see what @cviebrock thinks 🎅

[EspadaV8]

Just had a look at the support report and it doesn't contain the Container class so either was the package would need to be updated with (I'm guessing) foundation added as a requirement. (on my mobile so can't check easily).

I would probably recommend tagging a final 0.1x release and then release a new 0.2x for L5.2 and up.

[EspadaV8]

Hmm, okay, so the Container can't be injected because Commands don't get passed through the IoC and only SluggableMigrationCreator and an instance of Composer get passed in.

Using app()['composer'] works, but I'm not a great fan of using the global function.

What can be done though, is to remove the second parameter from the constructor and then use func_get_arg(1) to get the composer instance. I'm still not a great fan of this approach either.

[hiendv]

@EspadaV8 So should we change the namespace on a new release or using func_get_arg?

[cviebrock]

This PR looks good, but probably warrants a version bump. Let me take a look it all more closely in the next few days.

I wanted to do a major refactor of things for the next version, but I might not get to that in time, and I don't want to make things unusable for Laravel 5.2 users.

[hiendv]

We should have a branch for 5.2 or using IoC for resolving Composer so that it can be compatible with 5.*

[cviebrock]

So, I think there are now several items that need resolving for 5.2 compatibility.

First is the composer issue. Is there an injection we could make for Composer that works in 5.1 and 5.2? If so, let's use that. If not, I'd almost be tempted to just entirely remove the use of composer in that class, and not do the ->dumpAutoloads(), rather than come up with version-specific workarounds.

Second issue is the bindShared vs singleton. If we can just upgrade cocur/slugify to 1.4, then that's fine with me.

Finally, updating workbench and travis to support 5.2. It doesn't look like we can do this and make things compatible with 5.2 and earlier 5.* versions, does it? So, probably a new branch (and major version bump) are going to be needed anyway.

Sometime this holidays, I'll deal with it. :)

[cviebrock]

Try the 3.1.4 release.

I removed the composer reference to make it compatible with Laravel 5.2, and fixed composer.json so that it should work with all 5.x versions.

[Alvarad0]

Como puedo desinstalar la version mas reciente de Sluggable para instalar la version 3.1.4

[cviebrock]

Don't use 3.1.4. Use 4.0.1 now.