Grunt czy Gulp?

Raport z kolejnego dnia zabawy i przetwarzania nowy informacji :-)

Słowo wstępu

Od kilku lat używałem grunta

- Podoba mi się składnia
- Rozumiem jak działa
- Wiem czego mogę po nim oczekiwać.

Ostatnio pracując z generatorem yo,

poraziło mnie, że wszystkie projekty używają Glup.
- Składnia wygląda haotycznie
- Nie rozumiem skąd bierze dane ( tworzyłem jakieś zmienne środowiskowe wy uruchomić test)
- Dane są trochę wymieszane i muszę się wczytać by zrozumieć co gdzie jak.

Przykłady - porównanie...

Grunt: gruntfile.js


Wszystko chyba jasne
- config
- load Tasks
- register -> tworzenie tasków

jak patrze na Glup:gulpfile.js
 

To nie potrafię napisać takiego opisu w punktach
- Load zależności
- funkcje to zadania
- tworzenie tasków

hmmm sam nie wiem.

Sprawdziłem dane na https://www.npmjs.com/package

Jakie wnioski z repozytorium

Gulp:

Grunt:

1) ilość pobrań - Gulp
2) Wersja (ilość poprawek? ) - Gulp
3) ilość zgłoszonych problemów (issues) - Grunt
4) pull request (branches - odnogi projektu ) - Grunt ( czy to dobrze czy źle - wiele koncepcji twórców)
5) ostatnia poprawka - Gulp

+6) ilość członków zespołu według github
grunt 68, gulp 216

7) Gulp ma wiele zależności (node_modules), czyli jest podatny na problemy w modułach.

- Korzystając z wielu modułów, z których one same też korzystają z innych tworzy się łańcuch zależności gdzie zniknięcie jakiegoś małego nieistotnego modułu kładzie cały projekt. Przykładem było jak mały moduł który usuwał białe znaki znikł z repozytorium i klops, bo nikt nie wie co z czego wynika.

Wiosek

Grunt do nauki programowania i dla komercyjnych projektów. Ma niski poziom wejścia, po prostu go używamy.
Gulp dla wszystkiego pomiędzy. :-) Wymaga wiedzy i pozwala dużo dłubać w opcjach, posiada bardzo dużo opcji które pomagają tworzyć projekty dając dużego kopa na rozpęd.

Pozdrawiam.

Grunt - podsumowanie mojej zabawy z pakietami do automatyzowania pracy

Skoro ostatnio odrzuciłem na razie używanie generatorów, to może napiszę czego się nauczyłem?

mamy 2 pliki:

package.json

{
  "name": "project",
  "title": "file_project",
  "version": "0.0.1",
  "homepage": "localhost",
  "author": {name:"Born-kes"}
}

i Gruntfile.js
...

to w tym drugim, mogę korzystać z danych zadeklarowanych w innym miejscu:

np.

grunt.initConfig({
   pkg: grunt.file.readJSON('package.json'),

   concat: {
      dist: {
        src: ['<%= pkg.title %>/*.js', 'test/{,*/}*.js'],
        dest: 'dist/<%= pkg.name %>.js'
      }
   },
   uglify: {
      dist: {
        src: '<%= concat.dist.dest %>',
        dest: 'dist/<%= pkg.name %>.min.js'
      }
    },

Wniosek jak tego użyć?

Daje to wrażenie, że można mieć powiedzmy już gotowe konfiguracje i dołączać je grunt.file.readJSON do projektu, a większość zmian opiera się o plik package.json.

To wygląda zachęcająco.

Faworyt:

Chyba najczęściej używanym pakietem jest grunt-contrib-watch - obserwator projektu.
Przeładowuje on Tasksi po każdej modyfikacji i może "piszczeć" jak któryś task coś znajdzie np.zrobimy literówkę, albo coś przestało działać...

Zmniejszanie plików

grunt-contrib-uglify minimalizuje plik usuwając zbędne białe znaki i czasem nazwy zmiennych by skrócić kod. Szybko działa i pozwala mieć fajny przejrzysty kod z tysiącem komentarzy, a na boku tworzy kod czysty od naszych komentarzy i spakowany (zminifikowany).
grunt-contrib-htmlmin - minifikuje pliki HTML
grunt-contrib-cssmin - minifikuje pliki CSS

grunt-contrib-connect umnie strasznie zamula, ale odświerzanie okna przeglądarki po każdej modyfikacji to fajny bajer jak się ma dwa monitory.

grunt-usemin - pozwala podmieniać fragmenty kodu , np używać tagów w HTML do generowania strony bez potrzeby generowania jej przez serwer www.

Pilnowanie składni i poprawności kodu

grunt-contrib-jshint pozwala mieć konfiguracje w pliku w projekcie ( plik .jshint ), nie wiem co na to praktycy, ale chyba porządkuje kod.

grunt-eslint jest chyba lepiej wspierany (od grunt-contrib-jshint) , będę starał się go lepiej poznać. Kontroluje semantycznosć kodu, czyli między innymi literówki i poprawność.

grunt-contrib-concat pozwala łączyć pliki, ale szału niema, jeszcze nie jestem na etapie by każdy fragmęt kodu (funkcjonalność, zadanie) mieć w innym pliku.

grunt-karma - pozwala pisać testy jednostkowe.

Ciekawostka

NodeJS ma jeszcze dostęp do phpUnit od composera. Czytałem, że composer potrafi używać pakietów nodejs :-) - na stonie o drupalu 8, jest duży poradnik.
Ciekawostka może ktoś skorzysta, szkoda mi trochę czasu na takie zabawy.


Jak coś jeszcze znajdę to dopiszę do listy

Słowo wyjaśnienia i jada delej

Koniec roku szkolnego, więc trochę byłem zarobiony i nie było czasu napisać.

Rozwiązanie jest banalnie proste:
Każdy pakiet trzeba zainstalować osobno.

- ALE jak to!!?? - no tak to nie udało mi się wymusić automatycznej instalacji, czyli muszę nad tym jeszcze posiedzieć ( chce to zrozumieć, bo tak nie może być.. )

Szukam dalej i od nowa stawiam projekt, punktem wyjścia jest ostatni commit z Gita na dzień dzisiejszy.

Notatka:

1)
Polecenie "npm cache clear" w konsoli ma czyścić cache'a w razie problemów z instalacją.
Inna opcja to instalacja z flagą --cache pozwala z niego nie korzystać.

2)
udało mi się też wywołać błąd :-) , którego rozwiązaniem jest chyba właściwą kolejnością użycia komend.
Czyli odpowiednio najpierw

npm install

npm init

istnienie pliku package.json bez pakietów wywołało błąd i musiałem go usunąć i utworzyć chwilę później. Korzystając z gotowych pakietów można nawet nie wiedzieć o tej zależności.

END Notatka.


Co by nie było to trochę się nauczyłem - generatory nie są dla nowicjuszy :-)
Chyba że właśnie dla nich są napisane ( chyba takiego zrobię ).

Pozdrawiam