What is the difference between the "lib" and "vendor" folders?

Question

Regarding source folder hierarchy, there are always some common features, such as the src, doc or test folders, which have rather easy-to-understand contents.

However, I realized that big projects have both a lib and vendor folders, while I had always thought they were the same, as their names hint at including “third-party libraries from external vendors”. Though, seeing both in the same project means there is a difference.

I couldn't find any information nor on Google nor on sources such as the Filesystem Hierarchy Standard, even though this is actually a somehow common practice.

---

Here is a more detailed example with Symfony: once you create a project, you get a lib folder at the root of your project. In this folder, the following structure is found:

lib
+--filter
+--form
+--…
+--vendor
    +--simpletest
    +--symfony

Here, the symfony folder contains all Symfony's core.

Answer 1

When I see a lib or libraries directory, I think of:

• Libraries, not plugins, modules, etc.
• OOP instead of procedural, where that's applicable (i.e. PHP)

When I see a vendor directory, I think of:

• Libraries, plugins, modules, components, etc. Not just libraries, but anything that's provided by a third party.
• And stuff that's not code, like an icon set.

When I see lib and vendor directories, I think of a few distinctions:

1. lib holds only libraries, vendor may hold anything really,
2. lib is where I should put my libraries, vendor where I should put anything third party (including code by the original author),
3. lib is where libraries by the original author of the project are located (if that's not me), whereas vendor is where the original author put third party anything.
4. You can safely assume that whatever is in lib is licensed under the same license as the rest of the project.

Whichever one of the above applies, is reason enough to have different folders. AFAIK there is no generally accepted practice. Some communities have community wide common practices, but that's just about it.

---

As for the specific Symfony example: Symfony is a framework and I think what the developers are trying to say is that in a Symfony application the framework's core libraries are vendor code, i.e. coming from a third party and not from the original author of the application (you).

Answer 2

Generalizing @WayneM's answer but not daring to edit it so much.

So, it seems this structure can be observed in application frameworks (Rails and Symfony at least).

It is a way to keep the lib / src structure intact for application developers, while adding the other level of distance brought by the use of a framework: the vendor folder actually contains the framework's libraries, leaving the lib folder for the application's included libraries, and src for its source files.

It is a “more distant” lib, vital since without the framework, the application is useless, but not to be touched by the application's developer: it is the framework vendor's libraries.

Answer 3

In the case of something like Symfony, lib is the application code (i.e. written by the developers) and vendor is third-party code. Think of it like lib is what the src folder normally is, and vendor is lib. I normally see that style in PHP because you separate out the html templates from the actual classes.

Answer 4

From the Rails Asset Pipeline guide:

• app/assets is for assets that are owned by the application, such as custom images, JavaScript files or stylesheets.

• lib/assets is for your own libraries' code that doesn't really fit into the scope of the application or those libraries which are shared across applications.

• vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins and CSS frameworks.

I know this is not a Rails-specific question, but the explanation is good and clear and probably extends to other frameworks/project structures.