Czy warto rozwijać dwie podobne aplikacje jako jeden projekt?

Z ciekawości - jak byście podeszli do podobnej sytuacji:

Robię aplikacje Webową, i zauważam, że na jej podstawie można zrobić jeszcze jedną podobną aplikację która będzie miała dużo elementow wspolnych (JS, CSS) ale już na nieco inny temat, przez co na nową domenę.

Myślę, nad jednym repo, i 2 osobnymi taskami w gulpie 1 do budowania witryny 1 drugi do budowania witryny 2. zastanawiam sie troche tylko, czy z czasem nie zrobi sie "bur***" bałagan... jak np. dojdzie więcej elementów z czasem (na razie są małe).

Miałem kiedyś podobny case, aplikacja praktycznie za dużo się nie różniła (core był taki sam) była różnica jedynie w niektórych funkcjonalnościach. Padło na to aby zrobić osobne repa (sklonowanie istniejącego projektu i zmiana funkcjonalności w skopiowanym) z biegiem czasu uważam że była to dobra decyzja, ale jeżeli u Ciebie nie będzie dużych różnic to można zrobić to po prostu na branach i odpalanie tasków per merge do konkretnego brancha. Każde rozwiązanie ma swoje plusy i minusy.

B.Eng napisał(a):

Z ciekawości - jak byście podeszli do podobnej sytuacji:

Wszystko ma swoje zalety i wady. Ale ja widzę kilka możliwości:

• zrobienie na pałę - czyli skopiowanie czegoś wszystkiego albo kopiowanie fragmentów kodu - dobre doraźnie, ale nie jakbyś chciał długofalowo rozwijać część wspólną,
• monorepo (fajne bo wszystko razem, ale robi się burdel w commitach, jeśli robisz rzeczy z różnej parafii w jednym repo)
• Submoduły git - ???
• wydzielenie do osobnych repo - części wspólnej („silnika”) i oddzielenie apek, które z tego silnika korzystają. Jest to na pewno dobre podejście od strony architektury, jednak wtedy masz trzy różne repozytoria oraz zależności, które musisz synchronizować. Chociaż ja osobiscie bym w to szedł, tylko niekoniecznie od razu. Tj. monorepo wygodne byłoby wg mnie na początek (ale ze ścisłym oddzieleniem kodu silnika od apek. W końcu nawet w jednym repo można robić coś oddzielnie), ale potem możnaby to powydzielać rozsądniej, jeśli projekty by się rozrastały.

Myślę, nad jednym repo, i 2 osobnymi taskami w gulpie

Dlaczego chcesz to robić w Gulpie?
Nie sądziłem, że jeszcze ktoś tego używa. Przynajmniej nie w nowych projektach.

LukeJL napisał(a):

Dlaczego chcesz to robić w Gulpie?
Nie sądziłem, że jeszcze ktoś tego używa. Przynajmniej nie w nowych projektach.

a to mnie zaskoczyłeś. Są jakieś lepsze alternatywy? Ja gulpa uzywam po prostu jako task-runnera, do przygotowania JSa, CSSa na produkcje i zbudowania HTML z plików .pug

LukeJL napisał(a):

Wszystko ma swoje zalety i wady. Ale ja widzę kilka możliwości:

• zrobienie na pałę - czyli skopiowanie czegoś wszystkiego albo kopiowanie fragmentów kodu - dobre doraźnie, ale nie jakbyś chciał długofalowo rozwijać część wspólną,
• monorepo (fajne bo wszystko razem, ale robi się burdel w commitach, jeśli robisz rzeczy z różnej parafii w jednym repo)
• Submoduły git - ???
• wydzielenie do osobnych repo - części wspólnej („silnika”) i oddzielenie apek, które z tego silnika korzystają. Jest to na pewno dobre podejście od strony architektury, jednak wtedy masz trzy różne repozytoria oraz zależności, które musisz synchronizować. Chociaż ja osobiscie bym w to szedł, tylko niekoniecznie od razu. Tj. monorepo wygodne byłoby wg mnie na początek (ale ze ścisłym oddzieleniem kodu silnika od apek. W końcu nawet w jednym repo można robić coś oddzielnie), ale potem możnaby to powydzielać rozsądniej, jeśli projekty by się rozrastały.

właśnie gdzieś też tak myślę, mono, a potem ewentualnie rozdzielić, żeby nie robić bez sensu 3 repozytoriów do dwóch niewielkich aplikacji jak nie trzeba:P

B.Eng napisał(a):

a to mnie zaskoczyłeś. Są jakieś lepsze alternatywy? Ja gulpa uzywam po prostu jako task-runnera, do przygotowania JSa, CSSa na produkcje i zbudowania HTML z plików .pug

Gulp 5 lat temu ostatnio uaktualniany był na npm: https://www.npmjs.com/package/gulp
Na GH ostatni commit rok temu. Więc można chyba powiedzieć, że jest to projekt już nieutrzymywany.

Chociaż mimo to z jakichś powodów jest dalej używany przez niektórych (1 milion ściągnięć tygodniowo, co wydaje się dużo, ale porównując do różnych innych bibliotek JSowych, to wcale nie jest dużo), co mnie dziwi, bo już lata temu zaczęto od niego odchodzić, ale przypuszczam, że wiele z tego to legacy albo po prostu programiści ze starymi przyzwyczajeniami.

Z tego, co pamiętam, to popularność Gulpa spadła wraz z popularyzacją Webpacka, który rozwiązywał ileś problemów naraz w spójny sposób. Ponieważ Gulp jest tylko task runnerem, a nie bundlerem, to żeby zbudować projekt w Gulp, trzeba było instalować osobne wtyczki integrujące z docelowym narzędziem, jednak wtyczki te były często niezbyt często uaktualniane i często były z tym problemy - tu o tym piszą https://gist.github.com/elijahmanor/179e47828bf760c218bb3820d929836d#cons (w Webpack niby też się coś doinstalowuje, ale jakoś bardziej to z automatu działa)

Ja gulpa uzywam po prostu jako task-runnera

Task runner jest wbudowany w npm (scripts w package.json). Do dłuższych rzeczy można napisać osobny plik *.js. czy bash.

do przygotowania JSa, CSSa na produkcje i zbudowania HTML z plików .pug

No nie wiem, teraz takie rzeczy się załatwia bundlerami typu Webpack, Esbuild, czy jeszcze bardziej kompleksowymi narzędziami typu Vite.

Monorepo zawsze i wszędzie. Jedyną przeszkodą może być twoja wiedza i umiejętność pisania modularnego kodu w taki sposób, żeby nie skończyć ręką w nocniku

LukeJL napisał(a):

• monorepo (fajne bo wszystko razem, ale robi się burdel w commitach, jeśli robisz rzeczy z różnej parafii w jednym repo)

Jak będziesz robił to umiejętnie to nie ma problemy. Nawet można się pokusić o usunięcie jakiejś aplikacji (nadpisująć historię) przy pomocy git filter-repo w taki sposób, że znikną wszystkie zmiany odnośnie tego kawałka kodu (najlepiej jak wszystko jest w jednym podkatalogu)

• Submoduły git - ???

Nie znam nikogo, kto byłby zadowolony z submodułów do tego rozwiązania. Submoduły mają wady obu rozwiązań (tj. monorepo i osobne repo używane jako libka) a zalet żadnych

• wydzielenie do osobnych repo - części wspólnej („silnika”) i oddzielenie apek, które z tego silnika korzystają. Jest to na pewno dobre podejście od strony architektury, jednak wtedy masz trzy różne repozytoria oraz zależności, które musisz synchronizować. Chociaż ja osobiscie bym w to szedł, tylko niekoniecznie od razu. Tj. monorepo wygodne byłoby wg mnie na początek (ale ze ścisłym oddzieleniem kodu silnika od apek. W końcu nawet w jednym repo można robić coś oddzielnie), ale potem możnaby to powydzielać rozsądniej, jeśli projekty by się rozrastały.

To jest ok tylko trzeba się liczyć z tym, że nie możesz jednocześnie zmienić libki i klienta. To duży narzut i nie widzę za bardzo zalety przy takim zastosowaniu

Pewnie są na to lepsze rozwiązania, ale ja z powodzeniem nieraz zastosowałem najprostsze możliwe rozwiązanie tego problemu:

Jest projekt A i projekt B, zawierający identyczne pliki, z nich wybieram jeden z tych, ten, w którym częściej modyfikuje wspólne pliki, niech będzie to projekt A. Mam przygotowany skrypt bash, który kopiuje określone pliki z projektu A do projektu B z automatycznym nadpisaniem. Jeżeli potrzebuję coś zmienić w tych wspólnych plikach, to wykonuję modyfikację w projekcie A i odpalam skrypt, który zapewnia, że w obu projektach wspólne pliki są identyczne. Może być oczywiście drugi skrypt, który kopiuje wspólne pliki w drugą stronę.

Mając dwa wymienione skrypty bash, to obojętnie, w którym projekcie pracuję, to odpalając odpowiedni skrypt, mam zapewnione, ze te pliki, które mają być identyczne w obu projektach, są identyczne. W ten sposób mogę mieć np. 3 projekty i 3 skrypty, z których każdy kopiuje pliki do obu pozostałych projektów.