Advantages of moving vendor directory

Yii 2.0 General Discussions
1

Hi everybody,

first of all sorry about my english, it isn’t the best. Recently i’ve read the vendor directory can be moved from advanced template folder to another location, for example when we’re working with shared hosting.

So, basically i want to know what are the advantages of doing this. I guess according to this guide that we can save some space, but i also want to know if there are more.

2

I suppose one advantage would be to save space. Though to me, this reads as being a bit dangerous. If you have 10 different projects all sharing the one vendor directory, you may update one package/extension to satisfy the requirements of one project while unknowingly causing issues in another.

I wouldn’t recommend it unless space is an issue.

3

Hi artificial,

thanks for your response. Thinking in the dependences or in the specific version of a library is a very important point of view. Even now i remember that once i was expecting troubles with the dependencies of two libraries on two different projects with the same vendor directory.

I’ll keep using a separate folder for the vendor directory on my projects, until really needed to use it centralized.

Regards.

4

I agree with you two, artificial and José.

I think it’s far safer and simpler to have an independent vendor directory for each project than to share one among different projects.

In my disk, vendor directory consts 40 or 50 mb. Is it large and expensive? I don’t think so. I don’t see any decent reason to save this amount of disk space at the risk of possible dependency problem.

5

Guys,

let me tell you that i’m so grateful with your responses, the forum is really very useful.

Another important point appears when i’m using a centralized repository with git and yii2. Sometimes the commit, push or pull tasks take a lot of time, i guess it happens because the vendor directory has a lot of files.

Is there any good practice for it?

Regards.

6

You don’t add the vendor directory to source control - ignore it. It does not belong in a repository. :)

What you need to add to source control is composer.json.

And composer.lock if you are developing an application (and not a library).

7

Like jacmoe said, commit your composer.json and composer.lock file. When you clone down the repository elsewhere and go to set it up, you simply just have to run a composer install to pull down the vendor files.

There are use cases where you may want to commit the vendor directory (we have one such repository), although you generally wouldn’t for development.

8

jacmoe and artificial,

understood. I think it is so clear, i just need to ignore the vendor directory and just in particular cases when i really need it, i’ll commit it. Then i’ll take a advantage of composer when i need to clone the repository on production or anywhere.

thanks a lot. It is just in the way i was thinking. Sometimes you have ideas but you are not 100% sure of doing it in that way. One of the advantages of this forum is this, you can show your point of view and get the best solution or way with the community support

Regards.

9

Another reason not to share the same vendor directory ( for shared hosting especially) , is that if you put two different composer files ( one in Site A and one in Site B ) and update requirements in one but not in the other, when you update the one without the new package, it will remove the package from your shared vendor library.

You should only use a common vendor location if your apps are going to be updated with a single composer file in a master library/application. Otherwise, you’re going to be quite frustrated with the results.