Tworzenie pliku wykonywalnego

Dla tego demo, będziemy używać pkg narzędzia wiersza poleceń. Możesz swobodnie wybrać nexe lub inne, ale ja uważam, że pkg jest łatwiejsze w użyciu. Przede wszystkim, musimy zainstalować pkg globalnie używając komendy npm. Możesz również zainstalować go lokalnie, aby używać interfejsu CLI programowo.

$ npm install --global pkg

Gdy pakiet jest zainstalowany globalnie, dostajemy polecenie pkg do tworzenia plików wykonywalnych. Polecenie pkg wymaga pliku wejściowego, który jest wejściowym programem JavaScript, który zostanie uruchomiony, gdy użytkownik dwukrotnie kliknie na wygenerowany plik wykonywalny. Inne opcje wiersza poleceń kontrolują sposób generowania pliku wykonywalnego.

Plik wejściowy

Ścieżka pliku wejściowego jest dostarczana przez argument <input>, taki jak polecenie $ pkg server.js w naszym przypadku, który jest ścieżką do pliku lokalnego. Ale możemy również podać ścieżkę do package.json i polecenie pkg użyje bin właściwości package.json do zlokalizowania ścieżki pliku entry JavaScript. Jeśli podano ścieżkę do katalogu, to polecenie pkg szuka pliku package.json w tym katalogu używa jego właściwości bin.

Zasoby

Zasoby to zasoby statyczne, takie jak .html, .js, .css, .png, .json pliki, które powinny być dołączone do pliku wykonywalnego. Aby nakazać pkg włączenie takich plików do pliku wykonywalnego, musimy podać te ścieżki do plików poprzez pkg.assets właściwość package.json. Jej wartością jest wzorzec globalny lub tablica wzorców globalnych.

💡 W tym przypadku package.json powinna być ścieżką wejściową, aby pkg mógł wybrać assets, które są potrzebne do włączenia do pliku wykonywalnego.

Gdy plik wykonywalny zostanie utworzony, pkg włączy wejściowy plik JavaScript wraz z zasobami statycznymi do pojedynczego pliku wykonywalnego. W tym miejscu sprawy się trochę komplikują. Ponieważ wszystkie pliki projektu są teraz spakowane do pojedynczego pliku, względne ścieżki plików tracą swoje znaczenie, podobnie jak struktura folderów.

Ale w czasie wykonywania (gdy plik wykonywalny jest uruchomiony), pliki te są zorganizowane w wirtualny system plików zwany systemem plików migawkowych. Zazwyczaj te pliki w czasie wykonywania mają prefiks /snapshot/ (lub C:\snapshot\ w oknach) w swojej ścieżce, tak jakby znajdowały się wewnątrz katalogu /snapshot systemu.

Ale możesz bezpiecznie zlokalizować plik zasobów w pliku wykonywalnym (w czasie wykonywania), używając metody path.join i zmiennej __dirname do skonstruowania względnej ścieżki, takiej jak path.join( __dirname, './www/main.js' ). Ścieżka będzie działała tak samo dobrze, jak ścieżka do prawdziwego katalogu w prawdziwym systemie plików. Aby dowiedzieć się więcej o migawkowym systemie plików, przeczytaj tę dokumentację.

💡 Uważaj. Podczas procesu kompilacji, pkg patrzy na require() oświadczenia w kodzie i automatycznie dołącza te pliki jako zasoby statyczne. W związku z tym może nie być konieczne określanie takich plików jako aktywów statycznych w package.json. Istnieją jednak pewne zastrzeżenia, jak wyjaśniono tutaj.

Targets

Możemy wygenerować plik wykonywalny dla określonego systemu za pomocą flagi --targets wiersza poleceń. Wartością tej flagi jest łańcuch znaków w formacie <node>-<platform>-<arch>. Może to być również lista rozdzielona przecinkami tego wzorca, aby skierować się do wielu architektur systemowych. Można też użyć pola pkg.targets wzorca package.json, aby określić te wartości.

Wartość node to docelowa wersja major węzła. Wartość platform to nazwa docelowego systemu operacyjnego i może to być jedna z tych freebsd, linux, alpine, macos, win. Wartość arch to docelowa architektura procesora i może to być jedna z tych x64, x86, armv6, armv7.

Moglibyśmy pominąć jedną z tych wartości w specyfikacji celu. W takim przypadku pkg używa swojej wartości z bieżącej konfiguracji systemu. Możemy użyć 'host' jako wartości dla --targets w takim przypadku wszystkie te wartości są uzyskiwane z bieżącej konfiguracji systemu.

Wyjście

Postaramy się stworzyć pliki wykonywalne dla systemów operacyjnych macOS i Windows, szczególnie dla architektury procesora x64. Ponieważ naszym punktem wejścia jest server.js, użyjemy bin właściwości package.json, aby wskazać jego ścieżkę pliku. Ponadto wymienimy wszystkie ścieżki plików wewnątrz node_modules i src jako statyczne zasoby, ponieważ nasz server.js jest od niego zależny. Biorąc pod uwagę wszystkie te wymagania, nasz package.json wygląda jak poniżej.

Aby wygenerować binarne pliki wykonywalne, musimy wykonać polecenie pkg ., ponieważ chcemy, aby pkg użył pliku package.json z bieżącego katalogu do zlokalizowania pliku wejściowego, aktywów i celów. Możemy również użyć polecenia pkg package.json, które również robi to samo.

Po uruchomieniu tego polecenia pkg pobiera odpowiednie pliki binarne Node.js na podstawie wartości targets i buforuje je w katalogu określonym przez zmienną środowiskową PKG_CACHE_PATH, tak aby następnym razem, gdy napotkamy te same cele, pkg mógł użyć zbuforowanych plików binarnych.

Po pobraniu wszystkich plików binarnych pkg generuje pliki wykonywalne w bieżącym katalogu. Nazwa pliku i rozszerzenie tych plików są ustalane przez pkg i normalnie wyglądają jak <package>-<target>.<ext>, gdzie package jest wartością name w package.json.

Jednakże możemy kontrolować schemat nazewnictwa i katalog wyjściowy za pomocą wartości opcji --output lub --out-path. My użyjemy flagi --output do określenia katalogu wyjściowego i nazwy pliku wykonywalnego.

$ pkg --output build/web .

Powyższe polecenie generuje następujące pliki wewnątrz katalogu build.

node-js-executable
└── build
├── web-node10-win.exe (37.4mb)
└── web-node12-macos (43.4mb)

Teraz możesz dwukrotnie kliknąć dowolny z tych plików (zgodnie z Twoim komputerem), a otworzy się strona w domyślnej przeglądarce systemowej wyświetlająca wzór jednego sterownika.

.