Wpis z mikrobloga

@mathix: I tak, i tak. Przy korzystaniu z seeda użyłem jakiegoś najpopularniejszego generatora gruntowego do angulara, ale tam nie korzystałem z modułów, to tylko dorzuciłem Babel jako build step. Drugi projekt, gdzie stawiałem wszystko od 0, to już były moduły i to w TypeScript, to sobie postawiłem flow TS -> Babel -> Webpack na gulpie, całość kilkadziesiąt linijek.
  • Odpowiedz
@mathix: Bo TS to nie Babel i nie ma pełnego wsparcia dla kompilacji do ES5. Np. pętlę for..of skompiluje do zwykłego for (var i = 0; i < arr.length; ++i), ergo działa tylko dla tablic. Dlatego TS kompiluję z ustawieniem --target es6 (wtedy pętla for..of pozostaje pętlą for..of), a potem przejeżdżam to Babelem.
  • Odpowiedz
@Marmite: Nie wiedziałem o tym. Dzięki.

A jak sprawdzają się definicje dla angulara i innych libek? Wkurza mocno brak "intefejsów" czy do większosci są? A może po prostu olewasz temat i robisz typowane fasady na każdą bibliotekę, której używasz?
  • Odpowiedz
@mathix: Do większości bibliotek są, do popularnych takich jak Angular czy inne jQuery zawsze są aktualne, czasem są odrobinę przestarzałe (np. wczoraj ściągałem typy dla bibliotek z serii CreateJS i widzę że różnią się trochę (typy są dla 0.8.0, bibioteki są w wersji 0.8.2) i co prawda ci od CreateJS nigdy o semver nie słyszeli, bo zarówno 0.8.1 jak i 0.8.2 wprowadzają breaking changes, ale z changeloga widzę, że da radę),
  • Odpowiedz
@mathix: Ciężko powiedzieć, nie mierzyłem. Bardzo aktywnie korzystam z podpowiadania, więc jakieś tam przyspieszenie w stosunku do gołego JS, gdzie tylko garstka IDE ma naprawdę dobre podpowiadanie (zwłaszcza pomiędzy plikami) jest, oprócz tego czuję się po prostu bezpieczniej wiedząc że w tym miejscu na pewno jest taka zmienna, a nie że tylko wiem, że jest, bo czytałem w dokumentacji. Jeśli chodzi o IDE to Webstorm, VS i VS Code mają lepsze
  • Odpowiedz
@mathix: A tak wygląda task serve, wzięty z innego projektu: http://pastebin.com/m9aZ6f3J
I bardzo krótki gulpfile do niego:

gulp.task('clean:serve', clean);

gulp.task('serve', ['ts:serve', 'html:serve', 'scss:serve'], serve);

gulp.task('ts:serve', ['clean:serve'], ts);
gulp.task('ts-watch:serve', ts);

gulp.task('html:serve', ['clean:serve'], html);
gulp.task('html-watch:serve', html);

gulp.task('scss:serve', ['clean:serve'], scss);
gulp.task('scss-watch:serve', scss);

gulp.task('build', html);
  • Odpowiedz
@Marmite: Dzięki :). Popraw mnie jeśli źle myślę. Budujesz wszystko i pakujesz do jakiegoś folderu typu target albo dist i stamtąd serwujesz?
  • Odpowiedz
@mathix: W tym konkretnym przypadku akurat Cordova zajmuje się serwowaniem, a za każdym razem jak chciałem to jakoś sensownie ogarnąć, to się okazywało, że nie mam czasu :/ ale w tym innym projekcie to właśnie tak wygląda, że za każdym razem kompiluję wszystkie pliki ts, wrzucam je do folderu .tmp i stamtąd browsersync mi je serwuje. Plus odświeża stronę przy każdej zmianie, wiadomo.
  • Odpowiedz
@Marmite: A udało Ci się kiedykolwiek zastosować podejści src i dist? Imho takie kopiowanie i trzymanie osobnych wersji nie ma sensu, zapożyczyłem trochę idee z aurelii i JSPM. Skoro JSPM wykorzystuje "niemal" natywne podejście, więc defato nie ma źródeł tylko zawsze jest dist, a w wersji produkcyjnej wystarczy wygenerować build i po sprawie, ciekaw jestem jakie masz zdanie na ten temat.
  • Odpowiedz