¿Cuál es la estructura preferida de un proyecto Magento 2 bajo VCS?

Cuando comienzo un nuevo proyecto M2, lo primero que haría es instalar el núcleo a través del compositor:

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

Ahora puedo escribir mi (s) módulo (s) personalizado (s) y tema (s) debajo app/code. Luego agregaría mi composer.*y toda la app/codecarpeta a mi VCS. Hasta ahora todo está bien.

Supongamos que ahora quiero usar algunas herramientas de compilación para mi proyecto, digamos Grunt o Gulp.

1. Si confirmo el mío Gruntfile.js, el magento/magento2-basepaquete lo sobrescribirá cuando lo ejecute composer installdespués de clonar el repositorio.

2. Si confirmo mi gulpfile.js, realmente no puedo definir mis dependencias en a package.json, porque también sería sobrescrito por magento/magento2-base.

3. Si decido usar la configuración de Magento's Grunt y quiero personalizarla editando los archivos en /dev/tools/grunt(p themes.js. Ej. ), No puedo porque mis cambios se sobrescribirán magento/magento2-base.

Entiendo que realmente no puedes hacer mucho en la raíz de tu documento. Por supuesto, hay muchas soluciones a este problema:

• Podría ejecutar un git checkout -derecho después de la instalación para restablecer mis propios archivos
• Podría almacenar mis archivos de compilación en una carpeta dedicada, /buildpor ejemplo
• Podría usar una herramienta de compilación diferente, como Phing, Ant o Rake (mis desarrolladores frontend no estarían tan contentos)
• Podría reemplazarlo magento/magento2-basecon un paquete personalizado que tenga un mapeo personalizado para los archivos principales (no es realmente óptimo, pero bueno, es una opción)

Personalmente no me gustan todas estas opciones, por lo que me gustaría saber si hay una forma preferida o mejor de lograr lo que estoy tratando de hacer.

alguien esta teniendo el mismo problema? ¿Cómo lo resolviste? ¿Cómo estructura su proyecto bajo VCS?

ACTUALIZAR

Un punto extra relacionado con la configuración del proyecto. En mis experimentos, noté que el instalador del compositor Magento tiene una marca para anular archivos:

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

Se trata internamente como un booleano si no me equivoco, así que traté de configurarlo falsepara omitir la anulación. Cuando ejecuto composer installmi instalación falla debido a que los archivos ya están presentes. Básicamente, si no dejo que Magento anule mis archivos, no puedo instalarlo.

¿Cuál es el propósito de esta bandera entonces? ¿Se supone que solo debe realizar una verificación por mí? Para mí, no tiene mucho sentido ser honesto, pero tal vez alguien pueda arrojar algo de luz sobre el tema.

A corto plazo, estamos buscando separar archivos que necesitan personalización. Por ejemplo, si la gente necesita modificar index.php, descubra cómo separar el archivo estándar que Magento envía de la necesidad de personalizaciones locales. Una vez logrado, es posible tener "un verdadero .gitignore para que todos los proyectos puedan usar". Es decir, es fácil comprometer todo el directorio del proyecto a Git con .gitignore de todo lo que la "instalación del compositor" le proporcionará (y todo lo que la "actualización del compositor" reemplazará al instalar un parche o actualización).

A largo plazo, el objetivo es acortar .gitignore tanto como sea posible. Por ejemplo, inserte más en módulos bajo el directorio 'proveedor'

Luego

1. Para todo lo que no desea compartir entre proyectos, déjelo en la aplicación / código y comprométalo en el repositorio principal del proyecto.
2. Todo lo desarrollado localmente que desee compartir entre los proyectos con mayor facilidad, colóquelo en un repositorio GIT separado e instálelo a través del compositor para que termine en 'proveedor'. (Podría ser un repositorio de compositor local, o simplemente instalarlo directamente desde GIT).

De esa manera, aún puede hacer git commit de todo el árbol del proyecto de arriba hacia abajo, capturando los archivos composer.json y composer.lock (comprometer solo la aplicación / código no lo hace). El .gitignore excluirá el directorio 'vendor' y otros archivos no deseados.

Esto le brinda lo mejor de ambos mundos mencionados en la otra discusión. El problema actual es la longitud y la complejidad del archivo .gitignore, y la instalación del parche actualmente elimina algunas personalizaciones locales (por ejemplo, en index.php). Solución temporal a corto plazo: elimine index.php de .gitignore y, cuando instale un parche, verifique qué cambios perdió (git diff) y vuelva a aplicarlos manualmente.

Hay una solución fácil para su problema de anulación: no cambie los archivos principales;) Magento se basa en extender el Código y no en cambiarlo.

Lo primero es que no debe poner toda su carpeta de aplicación / código en un repositorio vcs. Cada componente de Magento (módulo, tema, etc.) debe ser un repositorio.

Si desea cambiar / ampliar el frontend, debe crear un nuevo tema y tratar este tema como su proyecto gruñón, no como toda la instancia de Magento2.

Para instalar su tema en su Proyecto, puede extraerlo fácilmente a través del compositor directamente desde su repositorio vcs

Ok, parece que encontré una mejor solución para lo que estaba tratando de lograr. En el composer.json, es posible especificar qué archivos deben ser ignorados por el instalador de Magento Composer. Si no quiero Gruntfile.jsque se anule, simplemente puedo especificarlo con la siguiente configuración:

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

Ahora puedo extender la instalación estándar para satisfacer mis necesidades.

Desafortunadamente, la respuesta aceptada, aunque originalmente fue la forma de lograr el objetivo deseado, solo funciona para excluir archivos y directorios ubicados en la raíz, porque si queremos excluir un archivo ubicado en un subdirectorio (por ejemplo dev/tools/grunt/configs/themes.js, es necesario si agregamos un nuevo tema y desea utilizar las tareas de Magento Grunt), colocándolo en la configuración "magento-deploy-ignore", bloquea la implementación de todos los directorios principales (es decir, dev y todos sus subdirectorios).

Esto sucede porque el método que procesa "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) utiliza strpospara hacer coincidir la ruta de destino con la lista de excluidos, por lo que cada ruta principal siempre devolverá verdadero.

Usando parches

Lo que uso es crear y aplicar parches. Cuando necesitemos cambiar dev/tools/grunt/configs/themes.js, index.phpo .htaccessapliquemos los cambios a una copia temporal del archivo y creemos un parche (cree un build/directorio primero):

$ 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

Entonces podemos hacer que este parche se aplique automáticamente cuando se ejecuta composer installo updateagregando los comandos te a la scriptssección de su composer.jsonarchivo:

{
    "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"
    }
}

(También podría poner el patch ...comando anterior en un script bash, digamos build/themes_patch.shy llamar a ese script desde Composer para que sea reutilizable o ejecutable manualmente)

¡Actualiza seguro! :RE

¡Esta solución es segura para actualizar! No está cambiando los archivos principales directamente sin respetar el archivo original. Está aplicando un parche al archivo Magento2 original. Cuando ese archivo cambia porque está actualizando, el parche fallará y sabrá que debe observar más de cerca los nuevos cambios y crear un nuevo parche.