Jaka jest preferowana struktura projektu Magento 2 w ramach VCS?

Kiedy rozpoczynam nowy projekt M2, pierwszą rzeczą, którą chciałbym zrobić, to zainstalować rdzeń za pomocą kompozytora:

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

Mogę teraz napisać moje niestandardowe moduły i motywy pod app/code. Następnie dodam mój composer.*i cały app/codefolder do mojego VCS. Jak dotąd wszystko jest w porządku.

Załóżmy, że teraz chcę użyć narzędzi do kompilacji dla mojego projektu, powiedzmy Grunt lub Gulp.

1. Jeśli popełnię własne Gruntfile.js, zostanie to nadpisane przez magento/magento2-basepakiet, gdy uruchomię composer installpo sklonowaniu repozytorium.

2. Jeśli popełniam moje gulpfile.js, nie mogę tak naprawdę zdefiniować moich zależności w package.json, ponieważ byłoby to również zastąpione przez magento/magento2-base.

3. Jeśli zdecyduję się użyć konfiguracji Grunt Magento i chcę ją dostosować, edytując pliki w /dev/tools/grunt(np. themes.js), Nie mogę, ponieważ moje zmiany zostałyby zastąpione przez magento/magento2-base.

Rozumiem, że tak naprawdę niewiele można zrobić w katalogu głównym dokumentu. Istnieje oczywiście wiele rozwiązań tego problemu:

• Mogłem uruchomić git checkout -zaraz po instalacji, aby zresetować własne pliki
• Mogę przechowywać swoje pliki kompilacji w specjalnym folderze, /buildna przykład
• Mógłbym użyć innego narzędzia do budowania, takiego jak Phing, Ant lub Rake (moi twórcy frontendu nie byliby jednak tacy szczęśliwi)
• Mógłbym zastąpić magento/magento2-baseniestandardowym pakietem, który ma niestandardowe mapowanie plików podstawowych (niezbyt optymalne, ale hej, jest to opcja)

Osobiście nie lubię tych wszystkich opcji, więc chciałbym wiedzieć, czy istnieje preferowany lub lepszy sposób na osiągnięcie tego, co próbuję zrobić.

Czy ktoś ma ten sam problem? Jak to rozwiązałeś? Jak tworzysz swój projekt w ramach VCS?

AKTUALIZACJA

Dodatkowy punkt związany z konfiguracją projektu. W moich eksperymentach zauważyłem, że instalator kompozytora Magento ma flagę do przesłonięcia pliku:

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

Jest to wewnętrznie traktowane jako logiczne, jeśli się nie mylę, więc próbowałem ustawić go tak, falseaby pomijał przesłonięcie. Po uruchomieniu composer installinstalacja kończy się niepowodzeniem, ponieważ pliki są już obecne. Zasadniczo, jeśli nie pozwolę Magento zastąpić moich plików, nie będę mógł ich zainstalować.

Jaki jest zatem cel tej flagi? Czy ma to na celu jedynie sprawdzenie mnie? Szczerze mówiąc, nie ma dla mnie sensu, ale może ktoś może rzucić nieco światła na ten temat.

Krótko mówiąc, szukamy osobnych plików, które wymagają dostosowania. Np. Jeśli ludzie muszą zmodyfikować plik index.php, dowiedz się, jak oddzielić standardowy plik dostarczany przez Magento od potrzeby lokalnych dostosowań. Po osiągnięciu tego, możliwe jest posiadanie „jednego prawdziwego .gitignore dla wszystkich projektów, z których można korzystać”. Oznacza to, że łatwo jest przekazać cały katalog projektu do Git za pomocą .gitignore wszystkiego, co „instalator instalacji” pobierze dla ciebie (i wszystko, co „aktualizacja kompozytora” zastąpi podczas instalowania poprawki lub aktualizacji).

W dłuższej perspektywie celem jest maksymalne skrócenie .gitignore. Np. Wepchnij więcej do modułów w katalogu „vendor”.

Następnie

1. Aby uzyskać wszystko, czego nie chcesz udostępniać między projektami, pozostaw to pod aplikacją / kodem i zatwierdzone w głównym repozytorium projektu.
2. Wszystko, co zostało opracowane lokalnie, które chcesz łatwiej udostępniać między projektami, umieść osobne repozytorium GIT i zainstaluj za pośrednictwem kompozytora, aby znalazło się pod „dostawcą”. (Może to być lokalne repozytorium kompozytora lub po prostu zainstaluj bezpośrednio z GIT.)

W ten sposób nadal możesz zatwierdzić całe drzewo projektu od góry do dołu, przechwytując pliki composer.json i composer.lock (nie działa tylko app / code). .Gitignore wyklucza katalog „vendor” i inne niepotrzebne pliki.

To daje najlepsze z obu światów wymienionych w innej dyskusji. Obecny problem polega na długości i złożoności pliku .gitignore, a instalacja łatki obecnie usuwa pewne lokalne dostosowania (np. W index.php). Obejście krótkoterminowe - usuń plik index.php z .gitignore, a po zainstalowaniu łatki sprawdź, jakie zmiany zostały utracone (git diff) i ponownie zastosuj je ręcznie.

Istnieje proste rozwiązanie dla problemu zastąpienia Problem: nie zmieniaj podstawowych plików;) Magento opiera się na rozszerzaniu Kodeksu i nie zmienianiu go.

Po pierwsze, nie należy umieszczać całego folderu aplikacji / kodu w jednym repozytorium vcs. Każdy komponent Magento (moduł, motyw itp.) Powinien stanowić samo repozytorium.

Jeśli chcesz zmienić / rozszerzyć frontend, powinieneś utworzyć nowy motyw i potraktować ten motyw jako swój cholerny projekt, a nie całą instancję Magento2.

Aby zainstalować motyw w projekcie, możesz łatwo pobrać go za pomocą kompozytora bezpośrednio z repozytorium vcs

Ok, wygląda na to, że znalazłem lepsze rozwiązanie tego, co próbowałem osiągnąć. W polu composer.jsonmożna określić, które pliki powinny być ignorowane przez instalator Magento Composer. Jeśli nie chcę, Gruntfile.jsaby moje ustawienia zostały zastąpione, mogę po prostu określić to w następującej konfiguracji:

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

Teraz mogę rozszerzyć standardową instalację, aby dostosować ją do moich potrzeb.

Niestety zaakceptowana odpowiedź, choć pierwotnie miała na celu osiągnięcie zamierzonego celu, działa tylko w celu wykluczenia plików i katalogów umieszczonych w katalogu głównym, ponieważ jeśli chcemy wykluczyć plik umieszczony w podkatalogu (np. dev/tools/grunt/configs/themes.jsPotrzebny, jeśli dodamy nowy motyw i chcesz korzystać z zadań Magento Grunt), umieszczając go w konfiguracji „magento-deploy-ignore”, blokuje wdrażanie wszystkich katalogów nadrzędnych (czyli dev i wszystkich podkatalogów).

Dzieje się tak, ponieważ metoda przetwarzająca \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnoredużycie „magento-deploy-ignore” ( ) strposdopasowuje ścieżkę docelową do listy wykluczonych, więc każda ścieżka nadrzędna zawsze zwróci true.

Używanie łatek

To, czego używam, to tworzenie i stosowanie łatek. Kiedy musimy zmienić dev/tools/grunt/configs/themes.js, index.phplub .htaccessmożemy zastosować zmiany do tymczasowej kopii pliku i utworzyć z niego łatę (utwórz build/dir pierwszy):

$ 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

Następnie możemy sprawić, że ta łatka zostanie zastosowana automatycznie podczas działania composer installlub updatepoprzez dodanie poleceń te do scriptssekcji twojego composer.jsonpliku:

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

(Możesz także umieścić powyższe patch ...polecenie w skrypcie bash, powiedzmy build/themes_patch.shi wywołaj ten skrypt z Composer, aby można go było użyć ponownie lub ręcznie)

Uaktualnij bezpiecznie! :RE

To rozwiązanie jest bezpieczne do aktualizacji! Nie zmieniasz bezpośrednio plików podstawowych bez przestrzegania oryginalnego pliku. Stosujesz łatkę do oryginalnego pliku Magento2. Kiedy ten plik zmienia się podczas aktualizacji, łatka nie powiedzie się i wiesz, że musisz przyjrzeć się bliżej nowym zmianom i utworzyć nową.