I'm being curious: I'm developing multiple plugins and often use composer to retrieve dependencies. Sometimes those dependencies have large require set of their own, like Ratchet, which depends on several Symfony components. From what I see versions of those packages are different from those required by Laravel. Same story applies to guzzle package which is often required in versions 3., 4. or 5. (guzzle is a bit different case, as they changed namespace in 3->4 version bump). Now the question I have is: are we in any way protected, by composer itself, or October, from version collision. As an example - lets say that October core depends on package SomeVendor/SomePackage in version 3.4.2 and some plugin has a dependency on SomeVendor/SomePackage in version 2.9.. Let's say that there is a major interface change between those versions and package is using identical namespace in both 2. and in 3.. I understand that october/laravel autoloader loads 3.4.2 version as soon as possible in application boot, then October PluginManager class kicks in and it requires 'vendor/autoload.php' file from all plugins that have that file, so version 2.9. gets loaded. Some time later some October code creates a new object from SomeVendor/SomePackage. Will it be a 3.4.2 or 2.9. or what's more important, is it possible that this will generate hard to find bugs?

I'm not exactly sure, but if you're running composer from the main directory, then the composer would handle this and probably error out if you have different versions for different packages.

That said, you're probably talking about how each plugin can have its own composer.json file and vendor packages are installed in the plugin directory. So I would think that this does NOT have any type of vendor version collision detection.

The only thing I can say is test it. Create 2 plugins, one pulling in one version, the other a different version of the same package. See how its used.

I'm very interested in what you find out.

Looks like I am a year late to the discussion, but did you figure it out? I had a similar issue when installing a library via Composer which had a dependency on a later version of Guzzle than the October Drivers plugin provides. It kept giving me errors showing conflict when trying to load Guzzle from the plugin. I found a work around, which doesn't use Guzzle, but I'm still learning so I'd like to do it right.

The only thing I can say is test it. Create 2 plugins, one pulling in one version, the other a different version of the same package. See how its used.

Okay, I did this and having the namespace problem. I installed guzzlehttp 6.5 version in on plugin and installed a guzzlehttp 7.0 version in another plugin. now it shows an error.

Symfony\Component\Debug\Exception\FatalThrowableError: Undefined class constant 'VERSION' in

Does anybody find any solution of it?