Hej chciałbym z mojego projektu stworzyć paczkę do instalacji przez composera i zastanawiam się jak powinienem ją zorganizować. W projekcie mam między innymi konfigurację Dockera i nie wiem czy to powinienem wykluczyć z paczki?
Co z plikiem composer.lock?

Ogólnie struktura mojego projektu wygląda tak jak na obrazku:


Wolałbym trzymać te wszystkie pliki w repozytorium, ale nigdy nie robiłem jeszcze paczek do composera i chciałbym uniknąć jakiegoś przypału, gdyby ktoś przypadkiem postanowił użyć mojej biblioteki ;-)

Poradzicie coś?

Nie wiem, czy przegapiłeś to w dokumentacji composer:
You should commit the composer.lock file to your project repo so that all people working on the project are locked to the same versions of dependencies (more below).

Dockera możesz wywalić bo jest zbędny. Jak go dołączysz to nic się wielkiego nie stanie. lock jak wyżej napisał kolega musi być.

Dobra faktycznie @pyro ma rację ad .lock

Dwa powyższe komentarze trochę bezrefleksyjne :-)

W przypadku, gdy tworzy się paczkę, którą ktoś może następnie pobrać np. z Packagista, wtedy NIE NALEŻY commitować `composer.lock`

// EDIT

Z tego co widzę vendor nie jest ignorowany? A powinien być

Przy okazji jak robisz paczkę, z którą mają korzystać inni, to dobrze żeby była przynajmniej w miarę pokryta testami

Ok czyli dockera zostawiam dla własnej wygody. Z composer.lock to już chyba będzie wyższa szkoła jazdy. Wczoraj wysłałem pierwszą wersję projektu do gitlaba z wykluczonym composer.lock i już na wstępie wywalił mi budowanie projektu, bo ten plik jest wymagany (testów jeszcze nie mam i nie wiem czy w tym projekcie będą, ale wynika z tego, że w samym repo na gitlabie warto trzymać composer.lock).
Z drugiej strony też mi się wydaje, że dla paczek composerowych nie powinno być. Czyli wynika z tego, że po drodze repo -> packagist trzeba jakoś ten plik wykluczyć. Jeszcze nie badałem tematu (nigdy nie tworzyłem paczek), ale pewnie jest na to jakiś automatyczny sposób, skoro w repo powinno się trzymać ten plik a w paczce już nie.

Dockera u siebie możesz zostawić dla wygody, jednak nie powinieneś go commitować (.git/info/exclude). Istnieją (z reguły rzadkie) przypadki, gdzie komponent może być dodany jako biblioteka do projektu jak i istnieć jako samodzielny serwis i wtedy może być commitowany, jednak patrząc po strukturze katalogów nic nie wskazuje na to żeby w tym przypadku miało tak być. Swoją drogą zastanawiam się po co Ci tutaj w ogóle ten docker, skoro nie widać nawet punktów wejścia. Jego użycie tutaj mija się z celem, zastanawiam się w jaki sposób to developowałeś

Jeżeli przy braku composer.lock wysypuje Ci się build, to oznacza kwestię nieprawidłowej konfiguracji builda / CI, a nie braku tego pliku.

To jest biblioteka, która służy do tworzenia i cachowania inlinowych preview obrazów, czyli w skrócie tworzy z dowolnego obrazka według zadanych filtrów preview i inlinuje go za pomocą base64 - to plus info o prawdziwmy obrazku zapisuje do cachu (u mnie redis, ale można też zrobić wersję plikową czy db).
Zamysł jest taki aby potem wykorzystywać to z jakąś biblioteką js do deferowania łądowania obrazów below the fold.
Tutaj taki przykład jak załadować stronę z 1.6mb obrazów w ~30ms: http://vps510947.ovh.net/inliner/deferred/index.html

Co do developmentu, to docker jest tak skonfigurowany aby root_dir miał w folderze examples, gdzie dałem różne sposoby użycia - na nich sobie developuje.

Zresztą tutaj jest samo repo: https://gitlab.com/hadwao/image-inliner

PS. Kod jeszcze nie jest skończony, na razie taki bardziej proof of concept, ale chce tą przekształcić w paczkę composera, aby wykorzystać testowo w jednym projekcie.

https://gitlab.com/hadwao/image-inliner/blo.../Dockerfile#L23



to kompletnie nie ma sensu. Wszystko co jest w Dockerfile z wyjątkiem komendy CMD/ENTRYPOINT jest wykonywane tylko podczas budowania, restartowanie serwisu kompletnie nie ma sensu. Zwłaszcza że obraz powinien wystawiać np proces który będzie kontrolowany za pomocą samego dockera (czy innego narzędzia), a nie jakiegoś dodatkowego systemu init (systemd, upstart, runit etc), to nie jest obraz maszyny wirtualnej, czy konfiguracja vagranta. Dlatego też apache działa tam jako foreground: https://github.com/docker-library/php/blob/...Dockerfile#L259

Co do samego tematu: jeżeli masz tylko jedną definicje Dockefile, nie używasz żadnych dodatkowych skryptów do inicializacji twojej aplikacji, to moim zdaniem najlepiej jakby był w root, zamiast ukrywania go gdzieś bezsensu.

Swoją drogą czemu PHP 7.0, który już nawet nie jest utrzymywany, zamiast 7.2 lub 7.3?

@by_ikar - dzięki za rozjaśnienie tematu z restartem. W Dockerze dopiero raczkuję i efekty osiagam głównie na zasadzie copy&paste. Wiem, że to nie najlepsza metoda, ale od czegoś trzeba zacząć ;-) To "ukrywanie" wynika z tego, że nigdy nie wiadomo jak się projekt potoczy i co jeszcze będzie potrzebne, więc o prostu trzymam się takiego standardu. Ale tak jak pisałem, dopiero zaczynam zabawę z Dockerem, więc nie wiem czy działam optymalnie.

@pyro - potrzebuję tej biblioteki do serwisu, który działa pod 7.0 i raczej nie zanosi się aby był upgradowany w najbliższych 2-3 latach.