Qual é a estrutura preferida de um projeto Magento 2 no VCS?

Quando inicio um novo projeto M2, a primeira coisa a fazer é instalar o núcleo via compositor:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

Agora posso escrever meu (s) módulo (s) personalizado (s) e tema (s) em app/code. Eu adicionaria minha pasta composer.*e toda a app/codepasta ao meu VCS. Até agora está tudo bem.

Suponha que agora eu queira usar algumas ferramentas de construção para o meu projeto, digamos Grunt ou Gulp.

1. Se eu confirmar meu Gruntfile.js, isso será sobrescrito pelo magento/magento2-basepacote quando executar composer installdepois de clonar o repositório.

2. Se eu confirmar minha gulpfile.js, não posso realmente definir minhas dependências em a package.json, porque ela também seria substituída por magento/magento2-base.

3. Se eu decidir usar a configuração Grunt do Magento e quiser personalizá-la editando os arquivos em /dev/tools/grunt(por exemplo themes.js), não posso, porque minhas alterações seriam substituídas por magento/magento2-base.

Meu entendimento é que você realmente não pode fazer muito na raiz do seu documento. Obviamente, existem muitas soluções para esse problema:

• Eu poderia executar um git checkout -logo após a instalação para redefinir meus próprios arquivos
• Eu poderia armazenar meus arquivos de compilação em uma pasta dedicada, /buildpor exemplo
• Eu poderia usar uma ferramenta de compilação diferente, como Phing, Ant ou Rake (meus desenvolvedores de front-end não ficariam tão felizes)
• Eu poderia substituir magento/magento2-basepor um pacote personalizado que possui um mapeamento personalizado para arquivos principais (não é realmente ótimo, mas ei, é uma opção)

Pessoalmente, não gosto de todas essas opções, então gostaria de saber se existe uma maneira preferida ou melhor de alcançar o que estou tentando fazer.

Alguém está tendo o mesmo problema? Como você resolveu isso? Como você estrutura seu projeto no VCS?

ATUALIZAR

Um ponto extra relacionado à configuração do projeto. Nas minhas experiências, notei que o instalador do Magento compositor possui um sinalizador para substituição de arquivos:

"extra": {
    "magento-force": "override"
}

Ele é tratado internamente como um booleano se não me engano, então tentei configurá-lo falsepara ignorar a substituição. Quando executo, composer installminha instalação falha devido aos arquivos já estarem presentes. Basicamente, se eu não permitir que o Magento substitua meus arquivos, não posso instalá-lo.

Qual é o objetivo dessa bandeira então? É apenas suposto executar uma verificação para mim? Para mim, não faz muito sentido ser sincero, mas talvez alguém possa esclarecer um pouco sobre o assunto.

Em curto prazo, procuramos separar arquivos que precisam de personalização. Por exemplo, se as pessoas precisarem modificar o index.php, descubra como separar o arquivo padrão que o Magento envia da necessidade de personalizações locais. Uma vez alcançado, é possível ter um ".gitignore verdadeiro para todos os projetos poderem usar". Ou seja, é fácil comprometer todo o diretório do projeto no Git com o .gitignore de tudo o que a "instalação do compositor" buscará para você (e tudo o que a "atualização do compositor" substituirá ao instalar um patch ou atualização).

A longo prazo, o objetivo é reduzir o .gitignore o máximo possível. Por exemplo, insira mais módulos no diretório 'vendor'.

Então

1. Para tudo o que você não deseja compartilhar entre os projetos, deixe-o em app / code e comprometido no repositório principal do projeto.
2. Tudo o que foi desenvolvido localmente que você deseja compartilhar entre os projetos com mais facilidade, colocar em um repositório GIT separado e instalar via compositor para que acabe em 'fornecedor'. (Pode ser um repositório de compositores local ou apenas instalar diretamente do GIT.)

Dessa forma, você ainda pode git comprometer toda a árvore do projeto de cima para baixo, capturando os arquivos composer.json e composer.lock (comprometendo apenas o aplicativo / código não). O .gitignore excluirá o diretório 'vendor' e outros arquivos não desejados.

Isso oferece o melhor dos dois mundos mencionados na outra discussão. O problema atual é o tamanho e a complexidade do arquivo .gitignore, e a instalação do patch atualmente elimina alguma personalização local (por exemplo, em index.php). Solução alternativa de curto prazo - remova o index.php do .gitignore e, quando instalar um patch, verifique as alterações perdidas (git diff) e reaplique-as manualmente.

Existe uma solução fácil para o seu problema de substituição: não altere os arquivos principais;) O Magento baseia-se em estender o código e não alterá-lo.

A primeira coisa é que você não deve colocar toda a pasta do aplicativo / código em um repositório vcs. Cada componente Magento (módulo, tema, etc ...) deve ser o próprio repositório.

Se você quiser alterar / estender o frontend, crie um novo tema e trate esse tema como seu projeto pesado, não como a Instância Magento2 inteira.

Para instalar o seu tema no seu projeto, você pode acessá-lo facilmente via compositor diretamente do seu repositório vcs

Ok, parece que encontrei uma solução melhor para o que estava tentando alcançar. No composer.json, é possível especificar quais arquivos devem ser ignorados pelo instalador do Magento Composer. Se eu não quiser que meu Gruntfile.jsseja substituído, posso simplesmente especificá-lo com a seguinte configuração:

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

Agora posso estender a instalação padrão para atender às minhas necessidades.

Infelizmente, a resposta aceita, embora tenha sido originalmente a maneira de atingir a meta desejada, funciona apenas para excluir arquivos e diretórios colocados na raiz, porque se queremos excluir um arquivo colocado em um subdiretório (por exemplo dev/tools/grunt/configs/themes.js, necessário se adicionarmos um novo tema e deseja usar as tarefas do Magento Grunt), colocando-o na configuração "magento-deploy-ignore", ele bloqueia a implantação de todos os diretórios pai (ou seja, dev e todos os seus subdiretórios).

Isso acontece porque o método que processa o "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) usa strpospara combinar o caminho de destino com a lista de excluídos, portanto, todo caminho pai sempre retornará verdadeiro.

Usando patches

O que eu uso é criar e aplicar patches. Quando precisamos alterar dev/tools/grunt/configs/themes.js, index.phpou .htaccessaplicamos as alterações a uma cópia temporária do arquivo e criamos um patch a partir dele (crie um build/dir primeiro):

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

Em seguida, podemos aplicar esse patch automaticamente ao executar composer installou updateadicionar comandos te à scriptsseção do seu composer.jsonarquivo:

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

(Além disso, você pode colocar o patch ...comando acima em um script bash, digamos build/themes_patch.she chamar esse script do Composer para que seja reutilizável ou executável manualmente)

Atualização segura! : D

Esta solução é segura para atualização! Você não está alterando os arquivos principais diretamente, sem respeitar o arquivo original. Você está aplicando um patch no arquivo Magento2 original. Quando esse arquivo é alterado porque você está atualizando, o patch falha e você sabe que precisa examinar mais de perto as novas alterações e criar um novo patch.