Większość swojego czasu spędzam programując w C# i w Visual Studio, wolny czas za to poświęcam na doskonalenie się w tym co robię na co dzień – czytam blogi, oglądam webcasty, próbuje napisać coś samemu, uczę się przez pisanie itp. itd.
Czasami jednak mam ochotę to wszystko rzucić i zając się czymś innym. Jakąś inna technologią. Innym środowiskiem. Wtedy poświęcam czas na poznawanie innych rozwiązań, nie zależnie od tego czy są stare czy też nie. Patrzę i oglądam i jak mi się podoba to zaczynam z tego korzystać tak często jak to tylko możliwe.
Tak też zaczęła się moja przygoda z Node.js – kilka lat temu spodobał mi się pomysł pisania aplikacji serwerowych w JS. Od tego czasu node jest u mnie zainstalowany na każdym komputerze i jak mogę to z niego korzystam.
Stwierdziłem więc, że może warto by było podzielić się kilkoma informacjami o tym innym od .NET środowisku, które bardzo szybko się rozwinęło, do tego stopnia, że MS sam się nim zainteresował (o czym poniżej). Także, tym o to postem rozpoczynam krótką serię, która będzie opisywała poszczególne narzędzia, stricte związane z node, a które jak zobaczycie są naprawdę niesamowite i dają nam w prosty sposób pełną kontrolę nad tym co chcemy uzyskać i jak.
Ok, a więc, Co to jest Node?
Node to środowisko do tworzenia skalowalnych aplikacji internetowych w JavaScript. To tak w skrócie ;) Dużo można już o tym środowisku przeczytać w sieci, więc jeżeli was ten krótki wstęp zainteresował to zachęcam do spojrzenia na to co umożliwia Node.JS, w szczególności iż instalacja jest beznadziejnie prosta – sciągamy plik msi ze strony node.js, uruchamiamy i przechodzimy przez kroki instalatora (lokalizacja itp). Po skończonym procesie w cmd
będziemy mieli dostępne polecenie node
.
Dla przykładu, napiszmy program w JavaScript:
function add(x, y) { return x + y; } console.log(add(2,2));
Zapiszmy go jako test.js
i następnie odpalmy:
node test.js
naszym oczom ukaże się:
$ node test.js 4
Prosto prawda? :)
Do tego warto wspomnieć, że za pomocą Edge.js możecie uruchomić aplikację node.js i .NET „in-process” na dowolnej platformie (win, mac czy linux) o czym ostatnio nawet Hanselman wspominał u siebie na blogu. Do tego MS zaczął już wspierać Node.js w Visual Studio za pomocą Node.js Tools for Visual Studio o czym też w zeszłym roku wspominał Hanselman, zaś dużo wcześniej w WebMatrix (info z 2011 roku).
Jak widzicie, node.js nie jest nowością. A wsparcie dla programistów .NET jest coraz większe. Warto więc na to zwrócić uwagę.
No ale dobrze, piszę cały czas o tym node, node tamto, node tam, itp. itd. ale co do jest ten NPM o którym w tytule wspomniałeś?
Node Packaged Module (NPM)
NPM, jest system paczek dla środowiska Node. Aktualnie tych paczek jest ponad 74 tysiące ich liczba wciąż rośnie. Jest on tym dla Node czym dla Visual Studio jest Visual Studio Gallery – Products and Extensions for Visual Studio z tą różnicą iż, wszystko jest dostępne poprzez NPM – jeżeli czegoś tam nie ma, to nie istnieje (śmieje się, ale taka prawda, jeżeli paczki nie znajdziecie w NPM to nikła szansa, że jest ona gdzieś gotowa i tylko czeka by ją sobie pobrać).
W naszym środowisku VS, część rzeczy dostępna jest jako paczka vsix a część jako normalna aplikacja instalująca się na komputerze (nCrunch, Resharper, dotTrace etc).
Tak czy siak, NPM spełnia te same założenia, co rozszerzenia do VS. Dostarcza on narzędzia serwerowe a nie klienckie – frameworkowe, a nie client side lib. Czasami pewne rzeczy które możemy ściągnąć NPM są jak paczki nugetowe – na przykład by napisać aplikację w Nancy, ściągamy paczkę Nancy. By napisać aplikację w express.js za pomocą NPM ściągamy paczkę i możemy zacząć tworzyć nasze rozwiązanie od podstaw. W innych przypadkach są one czysto środowiskowe.
Ogólnie, jeżeli chcemy coś napisać w Node i nie chcemy pisać wszystkiego od zera i podstaw, na pewno wykorzystamy NPM. Do tego, wiedza co to jest NPM i jak z niego korzystać będzie niezbędna do kolejnych postów w cyklu.
Jak z niego zacząć korzystać?
Jeżeli zaczynamy projekt i będziemy chcieli się nim podzielić ze światem, to warto stworzyć plik zawierający informację na temat paczek z jakich nasz projekt korzysta.
npm init
stworzy to nam plik packages.json
który zawiera informacje na temat naszego projektu (które możemy ale nie musimy uzpełniać) takie jak, nazwa, strona domowa, opis, autorzy itp. itd. ogólnie wszystko to co byłoby przydatne gdybyśmy chcieli nasz projekt opublikować tak by inni programiści mogli ściągnąć naszą paczkę za pomocą npm. Do tego, plik ten zawiera informacje z jakich paczek nasz projekt będzie korzystał lub korzysta.
Plik ten nie jest jednak wymagany by zainstalować paczkę (jeżeli nie chcemy się dzielić naszym projektem, będziemy na nim pracować na jednym komputerze, nie będziemy go przenosić itp) wystarczy polecenie:
npm install <package name>
Package name
, możemy albo pobrać ze strony npm albo za pomocą komendy search
. Tak czy siak, zaleca się korzystanie ze strony – będzie szybciej ;)
Jeżeli chcemy by nasza paczka która instalujemy znalazła się w package.json
musimy dodać opcję:
npm install <package name> --save npm install <package name> --save-dev npm install <package name> --save-optional
Trzy opcje, trzy różna miejsca do których trafi nam paczka. Zaleca się by --save
był wykorzystany wtedy kiedy paczki są niezbędne do uruchamiania środowiska/aplikacji (na przykład express.js lub jakiś inny framework), --save-dev
wtedy kiedy paczka niezbędna jest do rozwijania i testowania aplikacji (na przykład unit testing framework), --save-optional
jak sama nazwa wskazuje ;)
Dzięki wykorzystaniu tych opcji sami nie będziemy musieli tego wpisywać do pliku package.json
– zaoszczędzi nam to czas. Nawet jeżeli nie chcemy kodu publikować, warto stworzyć sobie plik package.json
i wykorzystywać opcje save w trakcie instalacji paczki, chociażby dlatego, że bardzo często folder w którym instalowane są paczki (node_modules
) ma zagłębienie większe niż 255 znaków, co skutecznie uniemożliwia przenoszenie folderu gdziekolwiek. Dobrą praktyką jest też nie wrzyucanie go na github :)
Dodatkowo, kiedy mamy te paczki w pliku możemy usunąć sobie katalog node_modules
, i wykonać polecenie:
npm install
które ściągnie nam wszystkie paczki na nowo :)
Przy instalowaniu warto jeszcze znać przełącznik -g
który zainstaluje nam paczkę globalnie i będzie ona dostępna wszędzie tam gdzie Node jest. Jednak liczba instalowanych paczek globalnie a lokalnie różni się znacząco na korzyść lokalnych. Z globalnych korzystam tylko wtedy kiedy sami autorzy piszą: instaluj globalnie :)
Do tego mamy masę innych komend, jak uninstall
czy update
(robią dosłownie to jak brzmią;)). Jeżeli chcecie poznać pełną listę komend, to zapraszam do dokumentacji lub cheatsheet. W pracy codziennie z node, najczęściej będziecie jednak wykorzystywać polecenia: init
, install
i update
. Rzadziej, uninstall
.
Podsumowanie
To tyle w pierwszym odcinku :) W kolejnym zaczniemy wykorzystywać NPM w celu zainstalowania narzędzi, bez których ciężko obejść się przy programowaniu aplikacji klienckich z wykorzystaniem node.
PS.: Kto z was się bawi/bawił node? Albo npm?
Ja sie bawilem, nowa wersja dotnetblogs na nodzie czeka na odkurzenie :)
W firmie mamy malego bota napisanego w nodzie, ktory przesyla nam info o buildzie z TC do HipChata.
“Czasami jednak mam ochotę to wszystko rzucić i zając się czymś innym. Jakąś inna technologią. Innym środowiskiem. ”
Też to miałem/mam :) Aktualnie w realizacji :P
Node.js się bawiłem – https://github.com/mpraglowski/live.moments (uwaga: nie zaglądać do npm_modules – same śmieci z eksperymentów różnych). Kod brzydki ale pisany w pierwszych 2 tyg po narodzinach Tomka – za to działa już od prawie roku :)
NPM jest sporo przyjemniejszy od nuget ale kilka rantów na działanie i wprowadzanie breaking changes w modułach już slyszałem :)
Comments are closed.