[5.2] Add tightenco/collect to replace section

[eFrane]

Since tightenco/collect is just standalone illuminate collections from support, this replace should be added.

[GrahamCampbell]

Sorry, we can't add unrelated packages to our composer file like that.

[mattstauffer]

@GrahamCampbell Are you sure about that?

[GrahamCampbell]

What I was really meaning is, I doubt we want to. Leaving for Taylor to decide. :)

[mattstauffer]

@GrahamCampbell Thanks Graham! :)

[eFrane]

how is this unrelated?

[mattstauffer]

If you want to see reasons for and against this PR, take a look at this thread. tighten/collect#4
@frankdejonge argues against this PR; others argue for it.

[GrahamCampbell]

In general third parties should not distribute laravel code like that. Laravel itself should publish this if it wanted it, surely?

[mattstauffer]

@GrahamCampbell ¯\(°_o)/¯ I agree! But after taking that stance, Taylor and I looked into what it would take for Illuminate to offer this and decided it added a ton of unnecessary complexity to the core for a relatively edge-case need.

So, with his blessing, Tighten took on the task of splitting it out for folks who need it separately.

[eFrane]

I absolutely agree with "Laravel should publish it", however since collect exists I thought this would be the right way to go.

[taylorotwell]

I agree that this is probably OK in the special case of tighten/collect which is an exact copy of collections including the namespace.

[mattstauffer]

Thanks @taylorotwell, @eFrane, and @GrahamCampbell 👍

And for future reference: if this sets a problematic precedent at any point in the future, please feel free to drop this line for the same of Laravel purity; I want this to be a service, not a burden.

[GrahamCampbell]

Note that this is still not going to work.

[GrahamCampbell]

You need to make the support subsplit replace it too...

[crynobone]

shouldn't it just be "tightenco/collect": "*". Since any version of tightenco/collect should be ignored

[GrahamCampbell]

No?

[eFrane]

As I understand it, tightenco/collect follows the version of illuminate/support, thus self.version is the correct constraint.

[crynobone]

If let say laravel/framework make a release today, and tightenco/collect are only available to run the subsplit/publish command few days/weeks (not saying it would be common, but possible). There wouldn't be any exact version available.

In this case, wouldn't both the package be installed? Or composer smart enough to validate "laravel/framework":"v5.3.0" with "tightenco/collect":"5.3.x-dev"?

[eFrane]

@GrahamCampbell This may be a dumb question, but where exactly is the "authoritative" illuminate/support composer.json? Is this just the one in the illuminate/support repo or are these generated during the subsplit process?

[GrahamCampbell]

The one in laravel/framework please. :)

[eFrane]

Then I don't get what there is to be done for

You need to make the support subsplit replace it too...

[GrahamCampbell]

Then I don't get what there is to be done for

https://github.com/laravel/framework/blob/5.2/src/Illuminate/Support/composer.json needs updating please.

[eFrane]

I'm so blind. Will do.