Post by Borys PogoreÅoPost by Cezary TomczykPost by Borys PogoreÅoA jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie
wszystko, to w końcu zwykły JS + strumienie.
No właśnie dlatego, że mam dostępny Promise, to Gulp nie jest mi potrzebny.
A nie widzę, byś go używał.
Nie. Aktualnie nie używam. A nawet przyznam się, że używałem Gulpa
bardzo króciótko i przy jednym projekcie. Grunt-a używałem przez kilka lat.
Post by Borys PogoreÅoDo tego to by jeszcze bardzo zaciemniło Twoje
rozwiązanie, zwłaszcza jakbyś musiał zsynchronizować kilka promises.
Promise.all - to wszystko, co jest potrzebne i jest dostępne. Chyba, że
myślisz o czymś innym.
Post by Borys PogoreÅoNie wspominając już o zabawie z łapaniem wyjątków, itd. Ze strumieniami jest
znacznie łatwiej, do ich scalania i synchronizowania masz gotowe narzędzia,
a ich użycie to 1-2 linijki.
"catch" z Promise-a powinien pomóc. Niektóre npm moduły zwracają Error
object.
Post by Borys PogoreÅoPost by Cezary TomczykTo żadna kombinacja. Przypatrz się temu dokładnie. Bierzesz pakiet npm i
używasz go całkiem normalnie: wejście -> wyjście.
A po drodze odpalasz binarkę CLI eslint, musisz ją skonfigurować,
samodzielnie obsłużyć błędy i do tego zupełnie nie widać, co jest wynikiem
działania tej funkcji. Coś tam sobie leci w pętli i nie bardzo wiadomo, co
A wrapper do G/G to jak działa?
Post by Borys PogoreÅosię dzieje i gdzie szukać efektów (co to jest "report" i jak go czytać? co
to jest "formatter" i czemu pojawia się dopiero na końcu, choć nazwa
wskazuje na coś potrzebnego w trakcie procesu?). A całość jest długa na dwa
Wszystko jest opisane w dokumentacji:
http://eslint.org/docs/user-guide/command-line-interface
Post by Borys PogoreÅoekrany. To nie jest proste rozwiązanie. Idealizujesz je, bo jesteś autorem.
Absolutnie nie idealizuję. Z resztą, nie wymyśliłem niczego nowego.
Przykładowo eslint
https://github.com/eslint/eslint/blob/master/Makefile.js korzysta z tego
samego podejścia do build-a.
Post by Borys PogoreÅoProste rozwiązanie to jest wziąć garść plików, złączyć je w jeden strumień,
wrzucić w eslint z konfiguracją i coś zrobić ze strumieniem wyjściowym. I
nie przejmować się zanadto obsługą błędów, bo robi to za nas narzędzie.
Jak masz proste kroki w buildzie, to wszystko się zgadza. Jeszcze raz
podkreślę - każdy używa to, co jest dla niego najlepsze albo musi, bo
jest już to w projekcie od jakiegoś czasu. Jeżeli ląduję w projekcie z
G/G, to nie marudzę tylko tego używam ;-)
A poza tym, zapominasz o innych argumentach. Przykład:
https://gist.github.com/elijahmanor/179e47828bf760c218bb3820d929836d
Post by Borys PogoreÅoPost by Cezary TomczykOsobiście, po jakimś czasie doszedłem do wniosku, że Grunt/Gulp za
bardzo ograniczają mnie i w zasadzie zdefiniowanie i napisanie kroków do
Ja mam nieodparte wrażenie, że gulpa nawet nie spróbowałeś na dobre, bo
wcześniej stworzyłeś to swoje rozwiązanie.
Próbowałem, ale bardzo krótko i przy jednym projekcie. Z resztą,
przeszedłem na inne podejście, które według mnie, jest bardziej
elastyczne. Może odrobinę więcej czasu zajmuje napisane zadania, ale nie
jest to też aż tak skomplikowane. Sądzę, że trochę przesadzasz w drugą
stronę ;-)
Post by Borys PogoreÅoPost by Cezary Tomczyk1. Definiujesz co chcesz osiągnąć.
2. Dobierasz sobie pakiet npm.
3. Piszesz kilka linijek kodu, by przekazać parametry do pakietu npm i tyle.
No popatrz, opisałeś gulpa ;)
:D
Post by Borys PogoreÅoHint: nikt Ci nie broni używać pakietów npm w procesie gulpa. Prościej
jednak jest trzymać się konwencji.
Trzymanie się konwencji jest pewnym ułatwieniem w organizacji pracy, ale
jednocześnie, osobiście, nie wykluczam indywidualnego podejścia.
Wszystko zależy od sytuacji i potrzeb.
Post by Borys PogoreÅoPost by Cezary Tomczyk* Usuwam niepotrzebną zależność od Grunt-a/Gulp-a
To nie jest argument.
W w/w linku są podane argumenty, a ja także podałem je w swoim artykule.
Post by Borys PogoreÅoPost by Cezary Tomczyk* Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go
Pakiety npm też nie zawsze są aktualne.
Pewnie, ale pakiety dla G/G jeszcze bardziej ;-)
Post by Borys PogoreÅoPost by Cezary Tomczyk* Nie muszę nic hackować, bo albo korzystam z gotowych pakietów npm
(jeśli są wystarczające), albo piszę sam.
A czym jest hackowanie, jak nie tym ostatnim? ;)
Hack to obejście. Ja niczego nie obchodzę :-) Ot, korzystam z pakietów
npm i tyle.
Post by Borys PogoreÅoNawiasem mówiąc pakiety gulp nie są jakieś przesadnie skomplikowane.
https://github.com/babel/gulp-babel/blob/master/index.js
No i teraz pytanie po co mi wrapper skoro mogę skorzystać bezpośrednio z
pakietu npm ;-)
Post by Borys PogoreÅoPost by Cezary Tomczyk* Do konkretnego zadania mogę wybrać jakikolwiek pakiet npm, spełniający
moje wymagania. Mając Grunt-a/Gulp-a muszę brać pod uwagę to, że pakiet
był specjalnie dla G/G.
Nie musisz, ale tak jest wygodniej.
No więc najpierw muszę znaleźć coś, co zadziała z G/G, a jeśli nie ma,
to pozostaje mi własne rozwiązanie, które potem muszę podpiąć pod G/G.
Post by Borys PogoreÅoPost by Cezary Tomczyk* Trzeba przeczytać i zrozumieć kod :D
* Więcej nie pamiętam, ale możesz dopisać kolejne punkty tutaj ;-)
* Tworzysz rozwiązanie in-house, z którym musisz sobie radzić sam
I tak, i nie. Po mojej "in-house" stronie jest tylko to, co ja
napisałem. Reszta to pakiety npm. Tak, czy inaczej, wsparcie community jest.
Post by Borys PogoreÅo* Musisz w wielu miejscach wynajdować koło na nowo
Nie bardzo wiem, co takiego muszę wynajdować na nowo.
Post by Borys PogoreÅo* Uzyskujesz strasznie rozwlekły kod, bo patrz wyżej
Nie powiedziałbym, że rozwklekły, ale ok. Za to mam pełną kontrolę i
swobodę nad tym, co określone zadanie ma robić. Poza tym, build piszesz
raz i działa latami. Nie trzeba do tego codziennie zaglądać, jak do
źródeł aplikacji ;-)
Post by Borys PogoreÅoPost by Cezary TomczykPost by Borys PogoreÅoWidzę, że w komentarzach Ci napisali w sumie to samo ;)
Zdania są podzielone i to jest normalne. Nie oczekuję tego, iż G/G
zostanie porzucony czy nagle wszyscy przestaną z tego korzystać.
Zaprezentowałem swój punkt widzenia.
Na blogaskach generalnie wypada chwalić w komentarzach, nawet takie
wynaturzenia jak JSS ;)
:-)
Jednym z plusów takiego rozwiązania, o którym napisałem, jest brak
zależności od konkretnego rozwiązania do builda.
Przy okazji, przypomina mi się sytuacja historycznie:
* Grunt - tego teraz używamy.
* Gulp - Grunt już je be, teraz Gulp jest super.
* Browserify - nie znasz? Teraz to jest na topie :-)
* Webpack - nie, już Browserify nie jest dobre.
* Rollup (http://rollupjs.org/) - teraz Rollup musi być najlepszy.
Ja wiem, że są rożnice w tym, co one potrafią, ale to już inna bajka.
--
Cezary Tomczyk
http://www.ctomczyk.pl/
