Natrafiłem (chyba) na wzorzec bulider przy okazji biblioteki do obsługi API Inposta.
https://github.com/t3ko/inpost-api-php-sdk

Natrafiam na dość prosty dziwny błąd i nie mam pewności czy to nieprawidłowe użycie klasy (to prosta wrzutka bez specyfikacji) czy błąd twórcy.
Błąd jest mało prawdopodobny bo biblioteka wg mnie jest napisana na wysokim poziomie a jego odtworzenie (pojawienie się) jest bardzo prawdopodobne.

Tak więc chce wysłać jedną paczkę takim kodem:

[PHP] pobierz, plaintext 
$api = new Client(config('inpost.login'), config('inpost.password'), config('inpost.testMode') ? Client::SANDBOX_API_ENDPOINT : Client::PRODUCTION_API_ENDPOINT);
$package = new SelfSentPackageBuilder('sender@gmail.com', 'A', 'client@gmail.com', '50000000', 'KAT213', ''); // wzorzec builder?
$shipments = [$package->build()];
dd($api->registerShipments($shipments));
[PHP] pobierz, plaintext 

Paczka się dodaje ale otrzymuje błąd.

Linia 168 https://github.com/t3ko/inpost-api-php-sdk/.../Api/Client.php

Ten błąd pojawi się za każdym razem gdy do metody registerShipments nie wyślę dwóch rodzajów paczek (dostarczanych samodzielnie do paczkomatu SelfSentPackage i odbieranych przez kuriera Package - jak dla mnie w 99% przypadków tak jest właśnie).

Wystarczy mała zmiana - w pliku głównym Client w linii 212 zmienić return z false, na return [] tak aby nie zwracało bool tylko pustą tablicę i wtedy nie wysypie się na mergingu. Niestety klasa jest w Vendors więc nie za bardzo można ją edytować i tak jak pisałem, jest szansa że źle jej używam więc przed jej nadpisywaniem wolałbym się upewnić.

Nie wiem czy jest sens analizowania biblioteki, która posiada taki dopisek:



Dodatkowo ostatnio zaktualizowana 3 miesiące temu, bez testów, a travis podpięty tylko na chwilę

Ten status jak dla mnie wynika z tego, że nie pokrywa ona większości API, a pokrywa funkcjonalność, która była aktualnie potrzebna autorowi (już mi na wstępie to troszkę przesadzało więc sobie rozszerzyłem klasę).
3 miesiące bez aktualizacji nie brzmi źle.. Obsługuje API o zaledwie jedno oczko do tyłu (wg autora). Co do testów nie "rzuciłbym pierwszy kamieniem"

Zrób sobie forka i popraw

A ten status, oznacza, ze to nie musi wcale działać

Nigdy nie wrzucałem nic na GIta i głupio mi forkować kogoś kto jest bardziej doświadczony
Muszę troszkę poczytać o tym.. Jak to wygląda licencyjnie itp.

Będę wdzięczny przynajmniej za potwierdzenie, że prawidłowo korzystam z wzorca.

No coz, autor za bardzo sie nie popisal, bo do array_merge wklada wynik funkcji $this->registerPackages a wynik ten moze byc zarowno tablica jak i FALSE, co tez w twoim przypadku (FALSE) ma miejsce.
$this->registerPackages() zwraca false w dwoch miejscach. Sprawdz, ktore z nich zwrocilo false a bedziesz wiedzial w czym problem

edit:
po szybkiej analizie widac, ze ty wrzucasz do tablicy wynik build() a ten skolei zwraca obiekt klasy SelfSentPackage
Pozniej jednak to wszystko jest filtrowane tym:
array_filter($shipments, function ($v) {
return ($v instanceof Package) && !is_subclass_of($v, '\T3ko\Inpost\Objects\Shipment\Package');
},
i wszystko wylatuje z filtra.... bezsens

Filtry są tam 2 dla dwóch rodzajów przesyłek. Te metoda po prostu inaczej traktuje każdy typ inaczej stąd ten filtr. No i gdy nie prześlesz chociaż po jednej paczce z tych dwóch typów wysypie się na merge.

Zrobiłem swojego FORKa z warunkami (choć proste rzutowanie na array tez powinno zdać egzamin).
https://github.com/mgralikowski/inpost-api-.../Api/Client.php
Ale nie potrafię wymusić w composer aby pobrał mój fork zamiast biblioteki wzorcowej.

Jak coś jest wystawione publicznie, to zawsze możesz to sforkować, tym bardziej na licencji MIT. A Open Source na tym polega, że community je wspiera. Jak wnosisz coś mądrego to nawet możesz zrobić pull requesta.

A co do samego problemu, to nwm jak działa po https, bo ja zawsze robię to po ssh, ale brakuje pewnie .git w url

Rozszerzenie .git nie jest wymagane, bardziej chodziło o prawidłowe nazwanie brancha: dev-master.
Udało się zaciągnąć forka.

a to tez prawda