Uparte narzędzia
Nie tak dawno temu na fejsowych grupkach poświęconych webdevowi zobaczyłem dwie rzeczy. Jedną z nich był news o nowej wersji jakiejś popularnej JS-owej biblioteki, w którym autor zastanawiał się, jak przetłumaczyć na polski słówko opinionated. Drugą był kod startera dla aplikacji w Next.js i Tailwindzie, który zawierał 20 plików konfiguracyjnych (22, jeśli doliczyć licencję i plik README). Co te posty mają ze sobą wspólnego? W sumie to nic, ale skłoniły mnie do dzisiejszej refleksji.
20 plików konfiguracyjnych. Swego czasu całe moje projekty posiadały mniej plików, niż ten starter konfiguracji. Ale potem coś się zdecydowanie zmieniło. Gdy teraz spoglądam na kod swojego bundlera, z przerażeniem stwierdzam, że metaplików (a więc zawierających jakąś konfigurację lub inne informacje o projekcie, nie zaś kod) jest podejrzanie wręcz dużo (15 plików i dwa katalogi). Na dobrą sprawę jest ich więcej niż faktycznego kodu. I z jednej strony to fantastycznie, że w JS-owym ekosystemie możemy sobie skonfigurować absolutnie wszystko, łącznie z dokładnym sposobem formatowania kodu. Tylko pytanie, czy na pewno potrzebujemy aż takiej swobody?
W PHP swego czasu rozwiązano ten problem dość efektywnie. Powstała grupa trzymająca władzę nieoficjalna organizacja tworząca standardy, PHP Framework Interop Group (PHP-FIG). Jej rekomendacje są przestrzegane przez większość PHP-owego światka, dzięki czemu ustalono m.in. standard nazewnictwa i automatycznego wczytywania modułów czy sposób formatowania kodu. Jasne, te rekomendacje nie mają żadnej mocy prawnej i w teorii nic się nie stanie, jeśli kod w PHP nie będzie ich przestrzegał. Ale stały się de facto standardem w PHP-owym ekosystemie i większość profesjonalnego kodu (zwłaszcza frameworków) będzie przestrzegała określonych przez PHP-FIG reguł. I dzięki temu, mimo że sam język nie definiuje dokładnych reguł dla wczytywania klas na podstawie ich nazwy, taka oddolna inicjatywa standaryzacyjna pozwoliła na stworzenie managera zależności, Composera. Tymczasem w ekosystemie JS-a teoretycznie mamy dość dobrze opisany sposób wczytywania modułów na poziomie samego języka. A mimo to ostatecznie niemal każdy framework ma swoje własne zdanie na temat tego, jak to powinno ostatecznie wyglądać. Nie wspominając już o tym, że manager pakietów też trzeba sobie najpierw wybrać.
I tutaj na scenę wkraczają opinionated rozwiązania. To angielskie słówko tłumaczy się dosłownie jako “uparty” i… podoba mi się to tłumaczenie. Bo tak, myślę, że potrzebujemy więcej upartych rozwiązań. Takich, które pozwalają zrobić coś w jeden, ściśle określony sposób. I których się nie da konfigurować. Dobrym przykładem może być formator kodu. Zwykle w projekcie używa się jednego sposobu zapisu. Co oznacza, że formator nie musi mieć miliarda opcji konfiguracyjnych, żeby dostosować każdy jeden przecinek i średnik. Wystarczy, żeby robił to tak, jak powinno być. Albo bundler. Konfiguracja webpacka jest już dzisiaj memem w branży, bo praktycznie nikt nie chce (czy wręcz nie jest w stanie) zrobić tego ręcznie. A przecież naprawdę sporo rzeczy można wyciągnąć bezpośrednio z pliku package.json, np. nazwy bundle’i, wersje Node’a, jakie mają być wspierane, itd. Mój bundler właśnie coś takiego robi, dzięki czemu nie potrzebuje żadnej dodatkowej konfiguracji. I chciałbym widzieć takich narzędzi zdecydowanie więcej.
Tak, cenię sobie konfigurowalność JS-owych narzędzi. Ale czasami po prostu chcę je zainstalować i nie musieć się ani razu zastanowić nad tym, czy aby na pewno są poprawnie skonfigurowane.
Komentarze
Przejdź do komentarzy bezpośrednio na Githubie.
Dawne komentarze
Ten blog wcześniej korzystał z systemu komentarzy Disqus. Jednakże pożegnaliśmy się i postanowiłem, że zaimportuję do nowej wersji stare komentarze z niego. Cóż, jego system eksportu na wiele nie pozwala…
Z tego, co wiem, PHP-FIG nie jest już uznawane przez najważniejsze frameworki. Symfony ma swój własny odpowiednik — Symfony Contracts.
Narzędzia nie powinny być opinionated. Powinny być elastyczne, aby można było je dostosować do specyficznych wymagań projektu. Ale powinny mieć na tyle dobre defaulty, że nikomu nie chce się tego zmieniać, chyba że jest to do czegoś potrzebne.
> Symfony ma swój własny odpowiednik — Symfony Contracts
Z oficjalnego repo Contracts:
> When applicable, the provided contracts are built on top of PHP-FIG's PSRs.
Więc oficjalnie Symfony nie jest częścią PHP-FIG, ale i tak trzyma się ich standardów tam, gdzie się da. No bo tak naprawdę nie da się ich nie przestrzegać. Nie w momencie, gdy Composer wymaga choćby autloadingu zgodnego z PSR.
Mhmm, już jakiś czas temu czytałem o pomysłach (np. link1, link2) przeniesienia plików konfiguracyjnych do innego folderu. Rozumiem głosy obu stron -- byłoby to i dobre i złe.
Jeden z głosów można by uznać, ze wpasowuje się w temat wpisu -- umieścić informację w
package.json. Trudno byłoby zgubić taki folder mając go jawnie w najważniejszym pliku w projekcie. Jednak pomyślałbym o rozwinięciu tej idei i udostępnieniu możliwości dziedziczenia(?) konfiguracji z pomocą instalowalnych modułów (np. z NPMa), trochę podobnie jak to robi ESLint.Wydaje mi się, że takie rozwiązanie udostępniałoby wolność w konfiguracji (dowolna, instalowalna od tak), konkretność w jej wskazaniu (za pomocą package.json), oraz "czystość" przestrzeni roboczej (brak 20 plików konfiguracyjnych).
---
Inna kwestia to czy nie wypadałoby przepisać jakichś starych rozwiązań ze względu na ich gorsze przystosowanie do współczesnych rozwiązań? Może gdyby takie narzędzie zacząć tworzyć dziś z dzisiejszym bagażem doświadczeń, to można by było stworzyć coś zarówno wydajniejszego i uwzgledniającego więcej przypadków (wchłaniając kilka konfiguracji do jednej). Ale to luźne przemyślenie wykreowane w trakcie pisania.
Ciekaw jestem jaką opinię na ten temat ma Pan Comandeer, prosiłbym o odpowiedź lub opisanie zagadnienia w dedykowanym wpisie ;p
Przeniesienie wszystkiego do `package.json` jest IMO średnim pomysłem. Ten plik bowiem zostaje opublikowany do rejestru npm, więc nie powinien być za duży. A jeśli będzie puchnął za bardzo od devowych rzeczy, to pakiety w npm-ie będą niepotrzebnie duże – co ostatecznie jest problemem dla całego ekosystemu. To, o co mi chodziło z `package.json`, to po prostu używanie przez narzędzia informacji, które już tam są standardowo.
Więc szczerze, to najbardziej mi się podoba przeniesienie configu do osobnego katalogu. Tylko że to bardziej zamiatanie problemu pod dywan, niż faktyczne jego rozwiązanie. Ale chyba jedyne, jakie pozwoli uporządkować ten bałagan, bo wspólny format konfiguracji dla różnych tooli to totalna utopia – zwłaszcza w ekosystemie JS. No chyba że nagle Biome czy podobny projekt zażre i jedno narzędzie zastąpi wszystkie inne.