Jeśli nie zwrócisz strumienia, wówczas asynchroniczny wynik każdego zadania nie będzie oczekiwany przez jego rozmówcę ani żadne zadania zależne.
Na przykład, gdy nie wraca strumienie:
$ gulp scripts
[21:25:05] Using gulpfile ~/my-project/gulpfile.js
[21:25:05] Starting 'tsc'...
[21:25:05] Finished 'tsc' after 13 ms
[21:25:05] Starting 'scripts'...
[21:25:05] Finished 'scripts' after 10 ms
[21:25:05] Compiling TypeScript files using tsc version 1.0.1.0
Uwaga tutaj, że zadanie scripts
zależy od zadania tsc
. Podaje, że tsc
kończy się w 13 milisekund, co jest zdecydowanie zbyt szybkie, aby można było rozsądnie uwierzyć. Zadanie scripts
wydaje się rozpocząć i zakończyć, ponownie w bardzo krótkim czasie. W końcu rozpoczyna się faktyczna operacja wykonana przez tsc
. Najwyraźniej ani tsc
, ani scripts
nie czekał na zakończenie etapu kompilacji.
Kiedy te zadania powrotu ich strumienie, wyjście wygląda zupełnie inaczej:
$ gulp scripts
[21:42:25] Using gulpfile ~/my-project/gulpfile.js
[21:42:25] Starting 'tsc'...
[21:42:25] Compiling TypeScript files using tsc version 1.0.1.0
[21:42:32] Finished 'tsc' after 6.65 s
[21:42:32] Starting 'scripts'...
[21:42:32] Finished 'scripts' after 204 ms
Oto sekwencja ma sens, a zgłoszone okresy sprostać oczekiwaniom.
Co zrobić, jeśli masz zadanie assemblowane, ale nie uwzględnia ono strumieni? Czy możesz wywołać funkcję 'done()' lub zwrócić obietnicę? – Bill
Możesz zdefiniować zadanie tak, aby akceptowało funkcję zwrotną jako parametr końcowy, lub możesz zwrócić obietnicę. Zobacz tutaj: https://github.com/gulpjs/gulp/blob/v3.9.1/docs/API.md#gulptaskname--deps-fn –