nodemon to narzędzie, które pomaga w tworzeniu aplikacji opartych na node.js poprzez automatyczne ponowne uruchamianie aplikacji node, gdy wykryte zostaną zmiany plików w katalogu.
nodemon nie wymaga żadnych dodatkowych zmian w kodzie lub metodzie rozwoju. nodemon jest zastępczym opakowaniem dla node. Aby użyć nodemon, zastąp słowo node w wierszu poleceń podczas wykonywania skryptu.
- Instalacja
- Użytkowanie
- Automatyczne ponowne uruchamianie
- Ręczne ponowne uruchamianie
- Pliki konfiguracyjne
- package.json
- Używanie nodemona jako modułu
- Używanie nodemona jako procesu dziecięcego
- Uruchamianie skryptów innych niż węzłowe
- Domyślne pliki wykonywalne
- Monitorowanie wielu katalogów
- Określanie listy obserwowanych rozszerzeń
- Ignorowanie plików
- Aplikacja nie uruchamia się ponownie
- Opóźnianie restartu
- Gracefully reloading down your script
- Kontrolowanie zamykania skryptu
- Wyzwalanie zdarzeń, gdy stan nodemona się zmienia
- Pipe output to somewhere else
- Używanie nodemona w twoim przepływie gulp
- Using nodemon in your Grunt workflow
- Wymowa
- Zasady projektowania
- FAQ
- Wspierający
- Sponsorzy
- Licencja
Instalacja
Albo przez klonowanie za pomocą git, albo za pomocą npm (zalecany sposób):
npm install -g nodemon
A nodemon zostanie zainstalowany globalnie w Twojej ścieżce systemowej.
Możesz również zainstalować nodemon jako zależność deweloperską:
npm install --save-dev nodemon
W przypadku instalacji lokalnej, nodemon nie będzie dostępny w Twojej ścieżce systemowej. Zamiast tego lokalną instalację nodemon można uruchomić, wywołując ją z poziomu skryptu npm (takiego jak npm start) lub używając npx nodemon.
Użytkowanie
nodemon opakowuje Twoją aplikację, więc możesz przekazać wszystkie argumenty, które normalnie przekazałbyś do swojej aplikacji:
nodemon
W przypadku opcji CLI użyj argumentu -h (lub --help):
nodemon -h
Używanie nodemona jest proste, gdyby moja aplikacja przyjmowała host i port jako argumenty, uruchomiłbym ją tak:
nodemon ./server.js localhost 8080
Wszystkie dane wyjściowe z tego skryptu są poprzedzone argumentem , w przeciwnym razie wszystkie dane wyjściowe z Twojej aplikacji, w tym błędy, zostaną wyemitowane zgodnie z oczekiwaniami.
Jeśli nie podano żadnego skryptu, nodemon sprawdzi, czy istnieje plik package.json i jeśli zostanie znaleziony, uruchomi plik powiązany z właściwością główną (ref).
Możesz także przekazać flagę inspect do node przez wiersz poleceń, tak jak normalnie:
nodemon --inspect ./server.js 80
Jeśli masz plik package.json dla swojej aplikacji, możesz całkowicie pominąć główny skrypt, a nodemon odczyta package.json dla właściwości main i użyje tej wartości jako aplikacji.
nodemon będzie także szukał właściwości scripts.start w package.json (od nodemon 1.1.x).
Sprawdź także FAQ lub problemy dla nodemon.
Automatyczne ponowne uruchamianie
nodemon został pierwotnie napisany do ponownego uruchamiania zawieszonych procesów, takich jak serwery internetowe, ale teraz obsługuje aplikacje, które czysto kończą pracę. Jeśli Twój skrypt zakończy pracę w sposób czysty, nodemon będzie kontynuował monitorowanie katalogu (lub katalogów) i zrestartuje skrypt, jeśli zajdą w nim jakieś zmiany.
Ręczne ponowne uruchamianie
Podczas działania programu nodemon, jeśli musisz ręcznie zrestartować swoją aplikację, zamiast zatrzymywać i ponownie uruchamiać program nodemon, możesz wpisać rs ze znakiem powrotu karetki, a nodemon ponownie uruchomi Twój proces.
Pliki konfiguracyjne
nodemon obsługuje lokalne i globalne pliki konfiguracyjne. Zazwyczaj noszą one nazwę nodemon.json i mogą znajdować się w bieżącym katalogu roboczym lub w katalogu domowym. Alternatywny lokalny plik konfiguracyjny można określić za pomocą opcji --config <file>.
Szczegółowość jest następująca, tak że argument wiersza poleceń zawsze zastąpi ustawienia pliku config:
- argumenty wiersza poleceń
- lokalna konfiguracja
- globalna konfiguracja
Plik config może przyjmować dowolne argumenty wiersza poleceń jako wartości klucza JSON, na przykład:
{ "verbose": true, "ignore": , "execMap": { "rb": "ruby", "pde": "processing --sketch={{pwd}} --run" }}
Powyższy plik nodemon.json może być moim globalnym configiem, dzięki czemu mam wsparcie dla plików ruby i plików przetwarzania, i mogę uruchomić nodemon demo.pde, a nodemon automatycznie będzie wiedział, jak uruchomić skrypt, nawet jeśli po wyjęciu z pudełka wsparcie dla skryptów przetwarzania.
Dalszy przykład opcji można zobaczyć w sample-nodemon.md
package.json
Jeśli chcesz trzymać wszystkie konfiguracje pakietów w jednym miejscu, nodemon obsługuje używanie package.json do konfiguracji.Określ konfigurację w takim samym formacie, jak w przypadku pliku konfiguracyjnego, ale pod nodemonConfig w pliku package.json, na przykład, przyjmij następującą package.json:
{ "name": "nodemon", "homepage": "http://nodemon.io", "...": "... other standard package.json values", "nodemonConfig": { "ignore": , "delay": "2500" }}
Zauważ, że jeśli określisz plik --config lub podasz lokalny nodemon.json, każdy package.json config jest ignorowany.
Ta sekcja wymaga lepszej dokumentacji, ale na razie możesz zobaczyć nodemon --help config (także tutaj).
Używanie nodemona jako modułu
Proszę zobaczyć doc/requireable.md
Używanie nodemona jako procesu dziecięcego
Proszę zobaczyć doc/events.md
Uruchamianie skryptów innych niż węzłowe
nodemon może być również używany do wykonywania i monitorowania innych programów. nodemon odczyta rozszerzenie pliku uruchamianego skryptu i będzie monitorował to rozszerzenie zamiast .js, jeśli nie ma nodemon.json:
nodemon --exec "python -v" ./app.py
Teraz nodemon uruchomi app.py z pythonem w trybie verbose (zauważ, że jeśli nie przekazujesz argumentów do programu exec, nie potrzebujesz cudzysłowów) i poszuka nowych lub zmodyfikowanych plików z rozszerzeniem .py.
Domyślne pliki wykonywalne
Używając pliku konfiguracyjnego nodemon.json, możesz zdefiniować własne domyślne pliki wykonywalne, używając właściwości execMap. Jest to szczególnie przydatne, jeśli pracujesz z językiem, który nie jest domyślnie obsługiwany przez nodemon.
Aby dodać obsługę rozszerzenia .pl (dla Perla), w pliku nodemon.json należałoby dodać:
{ "execMap": { "pl": "perl" }}
Teraz, po wykonaniu poniższych czynności, nodemon będzie wiedział, że ma używać perl jako pliku wykonywalnego:
nodemon script.pl
Zazwyczaj zaleca się używanie globalnego pliku nodemon.json do dodawania własnych opcji execMap. Jednakże, jeśli istnieje wspólna domyślna opcja, której brakuje, może ona zostać dołączona do projektu tak, aby nodemon obsługiwał ją domyślnie, poprzez zmianę default.js i wysłanie pull request.
Monitorowanie wielu katalogów
Domyślnie nodemon monitoruje bieżący katalog roboczy. Jeśli chcesz przejąć kontrolę nad tą opcją, użyj opcji --watch, aby dodać określone ścieżki:
nodemon --watch app --watch libs app/server.js
Teraz nodemon będzie się restartował tylko wtedy, gdy nastąpią zmiany w katalogu ./app lub ./libs. Domyślnie nodemon będzie przemierzał podkatalogi, więc nie ma potrzeby jawnego włączania podkatalogów.
Nie używaj globalizacji unixowej do przekazywania wielu katalogów, np. --watch ./lib/*, to nie zadziała. Potrzebna jest flaga --watch dla każdego obserwowanego katalogu.
Określanie listy obserwowanych rozszerzeń
nodemon -e js,pug
Teraz nodemon będzie się restartował przy każdej zmianie plików w katalogu (lub podkatalogach) z rozszerzeniami .js, .pug.
Ignorowanie plików
Domyślnie nodemon będzie się restartował tylko wtedy, gdy zmieni się plik .js JavaScript. W niektórych przypadkach można zignorować określone pliki, katalogi lub wzorce plików, aby zapobiec przedwczesnemu ponownemu uruchomieniu aplikacji przez nodemona.
Można to zrobić w wierszu poleceń:
nodemon --ignore lib/ --ignore tests/
Można też zignorować określone pliki:
nodemon --ignore lib/app.js
Można też zignorować wzorce (ale należy pamiętać o zacytowaniu argumentów):
nodemon --ignore 'lib/*.js'
Zauważ, że domyślnie nodemon będzie ignorował katalogi .git, node_modules, bower_components, .nyc_output, coverage i .sass-cache i doda Twoje ignorowane wzorce do listy. Jeśli chcesz rzeczywiście obserwować katalog taki jak node_modules, musisz zastąpić podstawowe domyślne reguły ignorowania.
Aplikacja nie uruchamia się ponownie
W niektórych środowiskach sieciowych (takich jak kontener z uruchomionym nodemonem czytającym przez zamontowany dysk), będziesz musiał użyć legacyWatch: true, który włącza polling Chokidara.
Przez CLI, użyj albo --legacy-watch albo -L w skrócie:
nodemon -L
Chociaż to powinna być ostateczność, ponieważ Chokidar będzie odpytywał każdy plik, jaki znajdzie.
Opóźnianie restartu
W niektórych sytuacjach możesz chcieć poczekać, aż pewna liczba plików się zmieni. Limit czasu przed sprawdzeniem zmian w nowych plikach wynosi 1 sekundę. Jeśli przesyłasz wiele plików i zajmuje to pewną liczbę sekund, może to spowodować, że Twoja aplikacja będzie się niepotrzebnie wielokrotnie uruchamiać ponownie.
Aby dodać dodatkową przepustnicę lub opóźnić ponowne uruchomienie, użyj polecenia --delay:
nodemon --delay 10 server.js
Aby uzyskać większą precyzję, można określić milisekundy. Albo jako float:
nodemon --delay 2.5 server.js
Albo używając specyfikatora czasu (ms):
nodemon --delay 2500ms server.js
Liczba opóźnienia to liczba sekund (lub milisekund, jeśli określono) do opóźnienia przed ponownym uruchomieniem. Zatem nodemon zrestartuje twoją aplikację dopiero po upływie podanej liczby sekund od ostatniej zmiany pliku.
Jeśli ustawiasz tę wartość w nodemon.json, będzie ona zawsze interpretowana w milisekundach. Np, poniższe wartości są równoważne:
nodemon --delay 2.5{ "delay": "2500"}
Gracefully reloading down your script
Możliwe jest wysłanie przez nodemon dowolnego sygnału określonego przez użytkownika do aplikacji.
nodemon --signal SIGHUP server.js
Twoja aplikacja może obsługiwać sygnał w następujący sposób.
process.once("SIGHUP", function () { reloadSomeConfiguration();})
Proszę zauważyć, że nodemon wyśle ten sygnał do każdego procesu w drzewie procesów.
Jeśli używasz cluster, wtedy każdy robotnik (jak również master) otrzyma ten sygnał. Jeśli chcesz zakończyć pracę wszystkich robotników po otrzymaniu SIGHUP, powszechnym wzorcem jest złapanie SIGHUP w masterze i przekazanie SIGTERM do wszystkich robotników, przy jednoczesnym zapewnieniu, że wszyscy robotnicy zignorują SIGHUP.
Kontrolowanie zamykania skryptu
nodemon wysyła sygnał zabicia do twojej aplikacji, gdy widzi aktualizację pliku. Jeśli musisz posprzątać po zamknięciu wewnątrz skryptu, możesz przechwycić ten sygnał i zająć się nim samodzielnie.
Następujący przykład nasłucha raz sygnału SIGUSR2 (używanego przez nodemona do ponownego uruchomienia), uruchomi proces czyszczenia, a następnie zabije się, aby nodemon mógł kontynuować kontrolę:
process.once('SIGUSR2', function () { gracefulShutdown(function () { process.kill(process.pid, 'SIGUSR2'); });});
Zauważ, że process.kill jest wywoływane tylko wtedy, gdy twoje zadania zamykania są zakończone. Czapka z głów dla Benjie Gillama za napisanie tej techniki.
Wyzwalanie zdarzeń, gdy stan nodemona się zmienia
Jeśli chcesz powiadomień typu growl, gdy nodemon się zrestartuje, lub wyzwolić akcję, gdy wystąpi zdarzenie, wtedy możesz albo require nodemona, albo dodać akcje zdarzeń do swojego pliku nodemon.json.
Na przykład, aby uruchomić powiadomienie na komputerze Mac, gdy nodemon uruchomi się ponownie, plik nodemon.json wygląda tak:
{ "events": { "restart": "osascript -e 'display notification \"app restarted\" with title \"nodemon\"'" }}
Pełna lista dostępnych zdarzeń jest wymieniona na wiki stanów zdarzeń. Zwróć uwagę, że możesz wiązać się zarówno ze stanami, jak i wiadomościami.
Pipe output to somewhere else
Używanie nodemona w twoim przepływie gulp
Sprawdź wtyczkę gulp-nodemon, aby zintegrować nodemona z resztą przepływu gulp w twoim projekcie.
Using nodemon in your Grunt workflow
Check out the grunt-nodemon plugin to integrate nodemon with the rest of your project’s gruntflow.
Wymowa
nodemon, czy wymawia się: node-mon, no-demon czy node-e-mon (jak pokémon)?
Cóż… pytano mnie o to wiele razy wcześniej. Podoba mi się, że mnie o to wcześniej pytano. Były zakłady co do tego, który to właściwie jest.
Odpowiedź jest prosta, ale być może frustrująca. Nie mówię (jak ja to wymawiam). To zależy od ciebie, abyś nazwał to jak chcesz. Wszystkie odpowiedzi są poprawne:)
Zasady projektowania
- Mniej flag jest lepsze
- Pracuje na wszystkich platformach
- Mniej funkcji
- Pozwól jednostkom budować na nodemonie
- Oferować całą funkcjonalność CLI jako API
- Wkłady muszą mieć i przejść testy
Nodemon nie jest doskonały, a argumenty CLI rozrosły się poza miejsce, w którym jestem w pełni szczęśliwy, ale być może pewnego dnia uda się to trochę zredukować.
FAQ
Zobacz FAQ i proszę dodaj swoje własne pytania, jeśli uważasz, że pomogłyby innym.
Wspierający
Dziękuję wszystkim naszym wspierającym! 🙏
Sponsorzy
Wspieraj ten projekt zostając sponsorem. Twoje logo pojawi się tutaj wraz z linkiem do Twojej strony internetowej. Zasponsoruj ten projekt już dziś ❤️
Licencja
MIT http://rem.mit-license.org