5 Likes
Interesant.
Nu stiam de multe din optimizarile cand ai un repo urias.
Nu stiam de git alias; dar pare util.
Interesant pachetul de pre-commit si husky, dar cred ca o sa raman pe clasicele git hooks.
Aflasem de git switch si git restore fix acum cateva saptamani, dar memoria degetelor a ramas pe git checkout.
Stiam de git attributes, dar nu prea l-am folosit like ever. Sunt curios acum daca nu pot avea alte unelte de diff pentru de exemplu sqlite.
Eu folosesc lefthook. Am folosit și husky dar era destul de ciudat/dificil de configurat[1] pentru nevoile de atunci, așa că am căutat o alternativă. 
Pre-commit n-am folosit vreodată, nici nu știu dacă știam de existența lui
de exemplu nu puteam configura să ruleze hooks diferit/extra pe local și tot configul trebuia ținut în
package.json. Acum văd că s-a schimbat și poți avea config în.husky. ↩︎
1 Like
Sunt niste dezavantaje majore la githooks.
Faptul ca nu sunt portabile este cel mai mare. Sa zicem ca ai un hook care ruleaza phpstan sau prettier. Pai tu trebuie sa ai phpstan sau prettier instalat, sau trebuie sa ai docker, sau trebuie sa fi facut un npm install. You never know.
Depind foarte mult de ce ai instalat. Ceea ce inseamna ca devin utile daca si numai daca fiecare developer are acelasi env.
Ma gandeam acum ca nu am problema asta pe NixOs. Pun un fisier default.nix in root, bam toata lumea are acelasi env si merg toate hookurile. Ba chiar pot sa il fac si mai portabil si sa pun shebangul in nix-shell, astfel incat sa mearga automagic daca ai nix sau altfel sa iti caute in pathul tau setat.
Stai sa vezi ce fain e daca un dev il dezactiveaza fiindca ii da eroare si nu poate face push si trebuie sa te certi cu el sa il reactiveze si sa citeasca erorile.
Daca nu folosesti WSL pe Windows o sa ai tot felul de probleme cu scripturile.
1 Like
Păi… nu de la premisa asta pleci, că toată lumea are același tooling?
Pipe dreams. Care sunt sansele sa ai fix acelasi env? Dar fix, la versiune?
Exemplu: unul cu prettier pe o versiune si altul care are prettier pe alta versiune si au outputuri diferite.
Singura sansa sunt vm-uri/containere preconfigurate, nix, dar cati fac asta?
Prettier nu cred ca e un exemplu bun fiindca il poti pune ca si dev dependency pe proiect si nu va fi rulat global, adica nu rulezi prettier global ci rulezi npm run lint care ruleaza prettier instalat in node_modules pe namespace/proiect. E o problema totusi in IDE (Visual Studio Code mi-a facut probleme destule, dar la git hook rulez altceva si la final mai dau un ammend dupa ce corecteaza - ca sa faci prettier/eslint sa fie egal in IDE si hook e o arta)
In plus eu mereu am un Makefile care verifica inclusiv ce versiune de node ai, e.g. pun make install ca si primul pas la instalarea proiectul care va rula npm ci doar daca ai versiunea de node care trebuie. Iar daca esti pe Windows trebuie sa folosesti o consola care poate rula makefile-ul.
In general o alta problema cu env variables se poate rezolva cu kentcdodds/cross-env: 
Cross platform setting of environment scripts (github.com)
Cea mai mare problema a mea e ca poate fi dezactivat sau cineva nu citeste README-ul la proiect. E.g. faci clone si dupa dai Install packages din IDE si incerci npm start si te plangi ca da erori fiindca n-ai versiunea buna de node si n-ai instalat nici hook-ul fiindca n-ai rulat npm ci ci IDE-ul a instalat altcumva pachetele.
Dacă reușești să-i convingi pe toți că folosiți PHP 8.3, de ce nu i-ai convinge și că folosiți Prettier x.y.z sau nu-știu-ce Pest sau altceva?
Mai ales că acum există soluții mai la îndemână, de genul dev containers sau ddev, unde tooling-ul ce trebuie instalat (manual) este minim.
Dev containers & co nu e un env reproductibil 100%, deoarece ai in spate docker pentru imagini.
Poti sa pui sha-ul, dar surpriza! Imaginea poate disparea oricand. Exemplu: la un moment dat se face un update de securitate pe o imagine de baza (debian, ubuntu) in general se sterg imaginile afectate de bugul acela. Si tu ramai cu buza umflata. Un dev poate sa aibe imaginea si sa-i mearga perfect deoarce ii este cache-uita, iar un dev nou nici nu poate sa o gaseasca.
Ok, sa zicem ca nu faci pinul asa de strict; sa zicem ca pui de exemplu ubuntu-23.04 ca si tag. Tagul respectiv primeste update-uri. Aceeasi situatie.
In toate situatiile astea singura varianta este sa iti faci un registry intern, cu propriile taguri, builduri samd. Nimeni nu face asta! Reproductibilitatea pe bune in docker e greu de atins.
1 Like