Яка краща структура проекту Magento 2 за VCS?

Коли я запускаю новий проект M2, перше, що я зробив би, це встановити ядро ​​за допомогою композитора:

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

Тепер я можу написати свої власні модулі (и) та теми (теми) під app/code. Потім я додав би мою composer.*та всю app/codeпапку до свого VCS. Поки все добре.

Припустимо, зараз я хочу використовувати деякі інструменти побудови для свого проекту, скажімо, Grunt або Gulp.

1. Якщо я зроблю своє Gruntfile.js, це буде замінено magento/magento2-baseпакетом, коли я запущу composer installпісля того, як я клонував репо.

2. Якщо я виконую свою gulpfile.js, я не можу реально визначити свої залежності в a package.json, тому що це також буде переписано magento/magento2-base.

3. Якщо я вирішу використовувати налаштування Grunt Magento і хочу налаштувати його, редагуючи файли в розділі /dev/tools/grunt(наприклад themes.js), я не можу, тому що мої зміни будуть замінені magento/magento2-base.

Я розумію, що ви не можете дуже багато зробити в корені документа. Звичайно, існує маса рішень для цієї проблеми:

• Я міг запустити git checkout -відразу після встановлення, щоб скинути власні файли
• /buildНаприклад, я можу зберігати свої файли збирання у спеціальній папці
• Я міг би скористатися іншим інструментом збирання, як-от Phing, Ant, або Rake (хоч мої розвідники не були б такі щасливі)
• Я міг би замінити magento/magento2-baseспеціальний пакет із спеціальним відображенням основних файлів (не дуже оптимальним, але ей, це варіант)

Мені особисто не подобаються всі ці варіанти, тому я хотів би знати, чи є кращий або кращий спосіб досягти того, що я намагаюся зробити.

Хтось має таку ж проблему? Як ти це вирішив? Як ви структуруєте свій проект під VCS?

ОНОВЛЕННЯ

Додатковий пункт, пов’язаний із налаштуванням проекту. У своїх експериментах я помітив, що інсталятор композитора Magento має прапор для перекриття файлів:

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

Це внутрішньо трактується як булевий, якщо я не помиляюсь, тому я спробував налаштувати його falseна пропуск головного. Коли я запускаю, composer installустановка не вдається через наявність файлів (файлів). В основному, якщо я не дозволяю Magento змінювати свої файли, я не можу його встановити.

Яка мета цього прапора тоді? Хіба лише припустимо, щоб я перевірив? Мені немає сенсу бути чесним, але, можливо, хтось може пролити трохи світла на цю тему.

За короткий термін ми шукаємо окремі файли, які потребують налаштування. Наприклад, якщо людям потрібно змінити index.php, розробіть, як відокремити стандартний файл Magento від необхідних локальних налаштувань. Після досягнення цього можливо мати "єдиний справжній .gitignore для всіх проектів, які можна використовувати". Тобто, легко надати Git цілий каталог проектів.

Більш тривалий термін - мета максимально скоротити .гігнорувати. Наприклад, більше натисніть на модулі в каталозі "постачальник".

Потім

1. Для всього, що ви не хочете ділитися між проектами, залиште це під додатком / кодом і виконайте це в основному репо-проекті.
2. Все, що розробляється на місцевому рівні, ви хочете легше ділитися між проектами, помістіть в окремий репортаж GIT та встановіть через композитор, щоб він опинився під "постачальником". (Можливо, це місцевий композитор-репо або просто встановити прямо з GIT.)

Таким чином, ви все ще можете запустити ціле дерево проекту зверху вниз, захопивши файли composer.json і composer.lock (якщо тільки додаток / код не робиться). .Gitignore буде виключати каталог "постачальник" та інші файли, які не потрібні.

Це дає вам найкраще з обох світів, згаданих в іншій дискусії. Поточний біль - це тривалість і складність файлу .gitignore, і встановлення патчів наразі знищує деякі локальні налаштування (наприклад, в index.php). Короткострокове вирішення - видаліть index.php з .gitignore, а після встановлення виправлення перевірте, які зміни ви втратили (git diff) та повторно застосуйте їх вручну.

Існує просте рішення для вашої проблеми перебору: не змінюйте основні файли;) Magento заснований на розширенні коду, а не на його зміні.

По-перше, ви не повинні поміщати всю папку додатків / кодів в одне сходове сховище. Кожен компонент Magento (Модуль, Тема тощо) повинен бути самим сховищем.

Якщо ви хочете змінити / розширити інтерфейс, вам слід створити нову тему і розглядати цю тему як ваш грубокопитний проект, а не весь екземпляр Magento2.

Щоб встановити тему у вашому проекті, ви можете легко перетягнути її через композитор безпосередньо зі свого сховища vcs

Гаразд, схоже, що я знайшов кращого рішення для того, що намагався досягти. У розділі composer.jsonможна вказати, які файли слід ігнорувати програмою Magento Composer Installer. Якщо я не хочу, щоб мій Gruntfile.jsперебір був, я можу просто вказати його за допомогою наступної конфігурації:

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

Тепер я можу розширити стандартну установку, щоб відповідати моїм потребам.

На жаль, прийнята відповідь, хоча спочатку призначена для досягнення бажаної мети, працює лише для виключення файлів і каталогів, розміщених у корені, тому що якщо ми хочемо виключити файл, розміщений у підкаталозі (наприклад dev/tools/grunt/configs/themes.js, необхідний, якщо ми додамо нова тема і хочуть використовувати завдання Magento Grunt), вводячи її в конфігурацію "magento-opens-ignore", вона блокує розгортання всіх батьківських каталогів (тобто, розробника та всіх його підкаталогів).

Це трапляється тому, що метод, який обробляє "magento-opens-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored), використовує strposдля узгодження цільового шляху зі списком виключених, тому кожен батьківський шлях завжди повертатиметься true.

Використання патчів

Що я використовую - це створення та застосування патчів. Коли нам потрібно змінити dev/tools/grunt/configs/themes.js, index.phpабо .htaccessзастосуємо зміни до тимчасової копії файлу та створимо з нього виправлення ( build/спочатку створіть dir):

$ 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

Тоді ми можемо змусити цей патч застосовуватись автоматично під час запуску composer installабо updateдодавши команди te до scriptsрозділу вашого composer.jsonфайлу:

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

(Крім того, ви можете поставити вищезазначену patch ...команду в скрипт bash, скажімоbuild/themes_patch.sh і зателефонуйте цьому скрипту від Composer, щоб він був багаторазовим або виконуваним вручну)

Оновлення безпечно! : D

Це рішення безпечне оновлення! Ви не змінюєте основні файли безпосередньо, не поважаючи оригінальний файл. Ви застосовуєте виправлення до оригінального файлу Magento2. Коли цей файл змінюється через оновлення, патч вийде з ладу, і ви знаєте, що вам слід уважніше ознайомитися з новими змінами та створити новий патч.