Quelle est la structure préférée d'un projet Magento 2 sous VCS?

Lorsque je démarre un nouveau projet M2, la première chose que je ferais est d'installer le core via composer:

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

Je peux maintenant écrire mes modules et thèmes personnalisés sous app/code. J'ajouterais alors mon composer.*et le app/codedossier entier à mon VCS. Jusqu'à présent, tout va bien.

Supposons maintenant que je veuille utiliser des outils de construction pour mon projet, disons Grunt ou Gulp.

1. Si je valide le mien Gruntfile.js, ce sera écrasé par le magento/magento2-basepackage lorsque j'exécuterai composer installaprès avoir cloné le dépôt.

2. Si je valide mon gulpfile.js, je ne peux pas vraiment définir mes dépendances dans a package.json, car il serait également écrasé par magento/magento2-base.

3. Si je décide d'utiliser la configuration de Magento Grunt et que je souhaite la personnaliser en modifiant les fichiers sous /dev/tools/grunt(par exemple themes.js), je ne peux pas car mes modifications seraient écrasées par magento/magento2-base.

Je crois comprendre que vous ne pouvez pas vraiment faire grand-chose dans la racine de votre document. Il existe bien sûr de nombreuses solutions à ce problème:

• Je pourrais exécuter un git checkout -droit après l'installation pour réinitialiser mes propres fichiers
• Je pourrais stocker mes fichiers de construction dans un dossier dédié, /buildpar exemple
• Je pourrais utiliser un outil de construction différent, comme Phing, Ant ou Rake (mes développeurs frontaux ne seraient pas si heureux cependant)
• Je pourrais remplacer magento/magento2-basepar un package personnalisé qui a un mappage personnalisé pour les fichiers de base (pas vraiment optimal mais bon, c'est une option)

Personnellement, je n'aime pas toutes ces options, je voudrais donc savoir s'il existe une façon préférée ou meilleure de réaliser ce que j'essaie de faire.

Quelqu'un a-t-il le même problème? Comment l'avez-vous résolu? Comment structurez-vous votre projet sous VCS?

MISE À JOUR

Un point supplémentaire lié à la configuration du projet. Dans mes expériences, j'ai remarqué que le programme d'installation de Magento composer a un indicateur pour remplacer le fichier:

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

Il est traité en interne comme un booléen si je ne me trompe pas, j'ai donc essayé de le régler falsepour ignorer la substitution. Lorsque j'exécute, composer installmon installation échoue car le ou les fichiers sont déjà présents. Fondamentalement, si je ne laisse pas Magento remplacer mes fichiers, je ne peux pas l'installer.

Quel est le but de ce drapeau alors? Est-ce seulement supposé effectuer un contrôle pour moi? Pour être honnête, cela n'a pas beaucoup de sens, mais peut-être que quelqu'un peut faire la lumière sur le sujet.

À court terme, nous cherchons à séparer les fichiers qui nécessitent une personnalisation. Par exemple, si les gens ont besoin de modifier index.php, découvrez comment séparer le fichier standard livré par Magento du besoin de personnalisations locales. Une fois atteint, il est possible d'avoir "un seul vrai .gitignore pour tous les projets utilisables". Autrement dit, il est facile de valider tout le répertoire du projet dans Git avec .gitignore de tout ce que "installer le compositeur" récupérera pour vous (et tout ce que "la mise à jour du compositeur" remplacera lors de l'installation d'un correctif ou d'une mise à niveau).

A plus long terme, l'objectif est de raccourcir autant que possible le .gitignore. Par exemple, pousser plus dans les modules sous le répertoire «vendeur».

alors

1. Pour tout ce que vous ne souhaitez pas partager entre projets, laissez-le sous app / code et validé dans le référentiel de projet principal.
2. Tout ce qui a été développé localement, que vous souhaitez partager plus facilement entre les projets, placez-le dans un référentiel GIT séparé et installez-le via le compositeur pour qu'il finisse sous `` fournisseur ''. (Il peut s'agir d'un dépôt de compositeur local, ou simplement installer directement à partir de GIT.)

De cette façon, vous pouvez toujours git valider la totalité de l'arborescence du projet de haut en bas, capturant les fichiers composer.json et composer.lock (la validation uniquement de l'application / du code ne le fait pas). Le .gitignore exclura le répertoire «vendeur» et les autres fichiers non souhaités.

Cela vous donne le meilleur des deux mondes mentionnés dans l'autre discussion. La difficulté actuelle est la longueur et la complexité du fichier .gitignore, et l'installation des correctifs efface actuellement certaines personnalisations locales (par exemple dans index.php). Solution de contournement à court terme - supprimez index.php de .gitignore, et lorsque vous installez un correctif, vérifiez les modifications que vous avez perdues (git diff) et réappliquez-les manuellement.

Il existe une solution simple pour votre problème prioritaire: ne changez pas les fichiers principaux;) Magento est basé sur l'extension du code et non sur sa modification.

La première chose est que vous ne devez pas mettre l'intégralité de votre dossier d'application / de code dans un référentiel vcs. Chaque composant Magento (module, thème, etc ...) devrait être un référentiel lui-même.

Si vous souhaitez modifier / étendre le frontend, vous devez créer un nouveau thème et traiter ce thème comme votre projet de grognement, pas l'ensemble de l'instance Magento2.

Pour installer votre thème dans votre projet, vous pouvez facilement le récupérer via le composeur directement depuis votre référentiel vcs

Ok, on dirait que j'ai trouvé une meilleure solution pour ce que j'essayais de réaliser. Dans le composer.json, il est possible de spécifier quels fichiers doivent être ignorés par le programme d'installation de Magento Composer. Si je ne veux pas que mon nom Gruntfile.jssoit remplacé, je peux simplement le spécifier avec la configuration suivante:

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

Je suis maintenant en mesure d'étendre l'installation standard pour répondre à mes besoins.

Malheureusement, la réponse acceptée, bien qu'elle soit à l'origine destinée à atteindre l'objectif souhaité, ne fonctionne que pour exclure les fichiers et répertoires placés à la racine, car si nous voulons exclure un fichier placé dans un sous-répertoire (par exemple dev/tools/grunt/configs/themes.js, si nous ajoutons un nouveau thème et souhaitez utiliser les tâches Magento Grunt), en le plaçant dans la configuration "magento-deploy-ignore", il bloque le déploiement de tous les répertoires parents (c'est-à-dire, dev et tous ses sous-répertoires).

Cela se produit car la méthode qui traite le "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) utilise strpospour faire correspondre le chemin de destination à la liste des exclus, donc chaque chemin parent retournera toujours vrai.

Utilisation de correctifs

Ce que j'utilise, c'est créer et appliquer des correctifs. Lorsque nous devons changer dev/tools/grunt/configs/themes.js, index.phpou .htaccessappliquer les modifications à une copie temporaire du fichier et en créer un patch (créez d'abord un build/répertoire):

$ 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

Ensuite, nous pouvons appliquer ce correctif automatiquement lors de l'exécution composer installou updateen ajoutant des commandes te à la scriptssection de votre composer.jsonfichier:

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

(Vous pouvez également placer la patch ...commande ci-dessus dans un script bash, disons build/themes_patch.shet appeler ce script depuis Composer pour qu'il soit réutilisable ou exécutable manuellement)

Mettez à niveau en toute sécurité! :RÉ

Cette solution est mise à niveau en toute sécurité! Vous ne modifiez pas directement les fichiers principaux sans respecter le fichier d'origine. Vous appliquez un correctif au fichier Magento2 d'origine. Lorsque ce fichier change parce que vous effectuez une mise à niveau, le correctif échoue et vous savez que vous devez examiner de plus près les nouvelles modifications et créer un nouveau correctif.