Qual é a diferença entre as pastas "lib" e "vendor"?

Em relação à hierarquia de pasta de origem, há sempre algumas características comuns, tais como o src, docou testpastas, que têm bastante fácil de entender o conteúdo.

No entanto, percebi que os grandes projetos têm pastas a libe vendor, embora eu sempre pensasse que eles eram iguais, pois seus nomes sugerem incluir “terceiros de librariesfora vendors”. Porém, vendo ambas no mesmo projeto significa que não é uma diferença.

Não encontrei nenhuma informação nem no Google nem em fontes como o padrão de hierarquia do sistema de arquivos , mesmo que essa seja realmente uma prática comum .

Aqui está um exemplo mais detalhado com o Symfony : depois de criar um projeto, você obtém uma libpasta na raiz do seu projeto. Nesta pasta, a seguinte estrutura é encontrada:

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

Aqui, a symfonypasta contém todo o núcleo do Symfony.

Quando vejo um diretório libou libraries, penso em:

• Bibliotecas, não plugins, módulos, etc.
• OOP em vez de processual, onde é aplicável (ou seja, PHP)

Quando vejo um vendordiretório, penso em:

• Bibliotecas, plugins, módulos, componentes, etc. Não apenas bibliotecas, mas tudo o que é fornecido por terceiros.
• E coisas que não são código, como um conjunto de ícones.

Quando vejo libe vendordiretórios, penso em algumas distinções:

1. libdetém apenas bibliotecas, vendorpode conter algo realmente,
2. libé onde devo colocar minhas bibliotecas, vendoronde devo colocar qualquer coisa de terceiros (incluindo código do autor original),
3. libé onde as bibliotecas do autor original do projeto estão localizadas (se não sou eu), enquanto vendorque o autor original coloca algo de terceiros.
4. Você pode assumir com segurança que o que estiver dentro libé licenciado sob a mesma licença que o restante do projeto.

Qualquer uma das opções acima se aplica, é motivo suficiente para ter pastas diferentes. AFAIK não existe prática geralmente aceita. Algumas comunidades têm práticas comuns em toda a comunidade, mas é exatamente isso.

Quanto ao exemplo específico do Symfony: Symfony é uma estrutura e acho que o que os desenvolvedores estão tentando dizer é que, em um aplicativo Symfony, as principais bibliotecas da estrutura são código de fornecedor, ou seja, provenientes de terceiros e não do autor original do aplicativo. (você).

Generalizando a resposta do @ WayneM, mas não ousando editá-lo tanto.

Portanto, parece que essa estrutura pode ser observada em estruturas de aplicativos (pelo menos Rails e Symfony).

É uma maneira de manter a estrutura lib/ srcintacta para os desenvolvedores de aplicativos, enquanto adiciona o outro nível de distância trazido pelo uso de uma estrutura: a vendorpasta realmente contém as bibliotecas da estrutura, deixando a libpasta para as bibliotecas incluídas no aplicativo e srcsua origem arquivos.

É um "mais distante" lib, vital, pois sem a estrutura, o aplicativo é inútil, mas não deve ser tocado pelo desenvolvedor do aplicativo: são as bibliotecas do fornecedor da estrutura .

No caso de algo como o Symfony, libé o código do aplicativo (ou seja, escrito pelos desenvolvedores) e vendoré um código de terceiros. Pense nisso como lib é o que srcnormalmente é a pasta e vendor é lib. Normalmente vejo esse estilo no PHP porque você separa os modelos html das classes reais.

No guia Rails Asset Pipeline :

• app/assets destina-se a ativos pertencentes ao aplicativo, como imagens personalizadas, arquivos JavaScript ou folhas de estilo.

• lib/assets é para o código de suas próprias bibliotecas que realmente não se encaixa no escopo do aplicativo ou nas bibliotecas compartilhadas entre aplicativos.

• vendor/assets é para ativos pertencentes a entidades externas, como código para plug-ins JavaScript e estruturas CSS.

Eu sei que essa não é uma pergunta específica do Rails, mas a explicação é boa e clara e provavelmente se estende a outras estruturas / estruturas de projeto.