Você deve executar o Composer no localhost e na produção?

Eu sou novo no Composer (getcomposer.org) e não estava certo de como funciona se eu instalar um pacote localmente usando o Composer e, em seguida, empurre minha base de código para o meu servidor de produção usando o Git. Preciso executar o Composer novamente no servidor de produção?

Cheers, J

Quando você configura seu projeto, você adiciona suas dependencies ao seu arquivo composer.json no diretório do projeto local.

Depois de ter feito isso, você precisará executar a atualização do compositor. Você também pode executar a instalação do compositor, no entanto, sem um arquivo composer.lock, a instalação do compositor realmente executa a atualização do compositor.

A atualização do compositor sai e resolve todas as dependencies de todas as bibliotecas que você está usando, as transfere para o diretório / fornecedor, cria um script de carregador automático e gera o arquivo composer.lock.

Para o seu projeto, o que você quer fazer é a versão do seu compositor.json e seu arquivo composer.lock.

No seu servidor de produção, você sempre executará a instalação do compositor, o que garante que as bibliotecas em seu servidor de produção são exatamente as mesmas que utilizou no seu processo de desenvolvimento.

A instalação do compositor também é muito mais rápida, pois não precisa fazer todo o trabalho de gerenciamento de dependência, e quase sempre pode simplesmente pular um commit # específico. Não precisa olhar para as cadeias de versão. Assim, geralmente é muito rápido, uma vez que um servidor já passou por uma vez.

Em desenvolvimento, a única vez que você deve executar a atualização do compositor, é quando você apresenta uma nova biblioteca OU você tem um problema onde uma biblioteca subjacente foi alterada e você sabe que precisa ter o compositor sair e recalcular as dependencies. A atualização do compositor sempre recalcula e baixa as revisões mais recentes de qualquer biblioteca disponível, mesmo que o nível da versão não tenha mudado. Isso significa que há um potencial para que algo se tenha quebrado, exigindo o potencial de um conjunto de testes de regressão tão completo como você pode ter disponível. Em suma, algo que não tem nada a ver com o que você está realmente mudando pode ter quebrado, então você só quer apresentar o potencial de mudança quando for forçado a fazê-lo.

Claro, se você introduziu uma nova biblioteca, não terá escolha senão executar a atualização do compositor.

Depois de executar a atualização do compositor, seu arquivo composer.lock será atualizado (como esperado) e o servidor de produção irá escolher isso quando você executar a instalação do compositor nele.

Como outros afirmam, coloque os vendedores no seu gitignore. O ponto é que estas são bibliotecas externas de que você depende, mas isso não pertence ao seu projeto e não deve ser versionado. Nos velhos tempos, algumas pessoas utilizavam os submódulos git, e é um grande PITA que você realmente quer evitar, para não mencionar que os submódulos não abordam as dependencies das bibliotecas que você incluiu.

Depende de como você está trabalhando. Se você, como diz o getcomposer.org, está ignorando a pasta “fornecedor”, então você precisa executá-lo novamente. Se você estiver selecionando a pasta “fornecedor”, não será necessário executá-lo novamente.

Tenha em mente que o compositor se encarregará de gerenciar suas versões de dependencies, portanto, não há necessidade de colocar seus arquivos de dependencies em versões. Se você colocou esses arquivos sob git, você só fará seu repository maior.

Leia https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies .

Para esclarecimentos quando ignora a pasta “fornecedor”, Git não rastreie os arquivos da pasta, então, se você clonar o retomado, será como compositor nunca foi executado