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

15

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.

fmrng
fuente
Tengo curiosidad por ver lo que otros publican como respuesta. Idealmente, creo que querríamos mantener a Magento Core fuera de nuestro repositorio principal y mantenerlo limitado solo a la plantilla que creamos y a cualquier complemento personalizado que agreguemos o corrijamos. Luego, en el momento de la compilación, hacemos referencia al núcleo + nuestro repositorio de proyectos y construimos un artefacto de aplicación a partir de los repositorios. Este es el método que he estado usando para M1 recientemente y me pregunto si la recomendación oficial de Magento es hacer algo similar con M2 ahora que Composer es totalmente compatible.
Bryan 'BJ' Hoffpauir Jr.
En las versiones más recientes M2, el Gruntfile.js, gulpfile.jsy el package.jsonproblema está resuelto. El problema abordado en esta pregunta todavía es aplicable a las versiones más recientes de Magento 2 cuando necesita cambiar themes.js, index.phpo .htaccesspor ejemplo.
7ochem

Respuestas:

4

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.

Alan Kent
fuente
OK, entonces cambiarás algunas cosas allí en un futuro cercano, ¡qué bueno! Me pregunto si esta "magento-force": "override"bandera podría ser útil de alguna manera. Por el momento no está haciendo exactamente lo que esperaría. En caso de que haya editado / extendido su index.phpo cualquier otro archivo "central", simplemente puede decirle a Magento que no sobrescriba sus cambios. ¿Tiene algún sentido?
fmrng
3

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

David Verholen
fuente
Bueno, la app/codecarpeta está específicamente allí para personalizar Magento. Mi comprensión del M2 actual es que app/codereemplaza lo que app/code/localestaba en M1, y los módulos de la comunidad se pueden instalar a través del compositor debajo vendor. Tenemos algunos proyectos con una gran cantidad de módulos y varios temas también. Lo que está sugiriendo sería imposible de manejar.
fmrng
Oye, gestionamos proyectos con> 100 componentes de esa manera. La clave es mantener los módulos pequeños y administrar sus dependencias de compositor entre los módulos. Puede clonar el repositorio de proyectos de magento para sus propias necesidades y agregar todos sus componentes a su proyecto
David Verholen
Si está satisfecho con su configuración actual, está bien. Sinceramente, me resulta bastante engorroso. Significa que tiene más de 100 repositorios git, y cada vez que está cambiando algo tiene que abrir un proyecto específico, confirmar sus cambios, ejecutar composer update. ¿Dónde comprometes tu composer.lockentonces? Si tienes más de 10 desarrolladores trabajando en el mismo proyecto, podría resultar realmente complicado. Por supuesto, tenemos muchos módulos generales (e incluso temas) que instalamos a través del compositor, pero el código específico del proyecto debe versionarse bajo el mismo repositorio para mayor claridad.
fmrng
No digo que lo estés haciendo mal, creo que es un poco complicado para mi gusto. Por interés, ¿cómo inspecciona su historial de repositorios con una configuración de este tipo? ¿Cómo puede usar características como git blameo git logcuando el código está disperso en múltiples componentes? ¿Ejecutas pruebas de integración para ver que todo funciona bien?
fmrng
tuvimos esta discusión internamente el año pasado y las implementaciones se volvieron bastante simples ya que decidimos hacerlo 1repo = 1module. El punto es que no harías una actualización del compositor para un pequeño cambio. Los desarrolladores trabajan en entornos de desarrollo y cambian los archivos allí directamente. Cuando terminan, pueden etiquetarlo como alfa, beta o candidato de lanzamiento. De esta manera, varios desarrolladores pueden trabajar en muchos proyectos al mismo tiempo y la próxima vez que realice una actualización del compositor, incorporará todos los cambios. Existen excelentes herramientas para organizar sus vcs y paquetes de compositores. Cientos de repositorios no deberían ser un problema
David Verholen
2

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.

fmrng
fuente
Esta solución no parece "actualización segura". Si Magento hará cambios en estos archivos que ignoras, entonces no lo sabrás o te olvidarás de estos archivos. Está utilizando su propia versión que nunca incluirá estos nuevos cambios. Por favor revise mi respuesta para mi sugerencia.
7ochem
2

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.

Gennaro Vietri
fuente
Lo sé, podría ver eso en mis pruebas, pero como estamos usando un flujo de trabajo de compilación diferente, funciona bien para nosotros. ¿Podrías encontrar una mejor opción?
fmrng
Comenzamos a hacer el pago de los archivos durante la fase de construcción de nuestra tubería, luego dejamos de usar todas las tareas integradas de Grunt, así que atm no es un problema.
Gennaro Vietri
Por cierto, comenzamos a evaluar el fork magento-composer-installer para mejorar el comportamiento de "magento-deploy-ignore", si el problema reapareciera podríamos seguir este camino
Gennaro Vietri
0

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.

7ochem
fuente