Node.js 응용 프로그램을 단일 실행 파일로 포장합니다.
node-packer 로 프로젝트를 컴파일하는 데 5 분도 채 걸리지 않습니다.
일반 Node.js에서 작동하는 한 어떻게 개발하든 응용 프로그램에서 단일 줄의 코드를 수정할 필요가 없습니다!
창문,
마코스와
리눅스require 지원합니다 (예 : require(myPath + 'module.js' ).다음은 최신 안정 Node.js Packer 릴리스입니다.
| OS | 아치. | 실행 파일 |
|---|---|---|
| 창 | x64 | https://gw.alipayobjects.com/os/enclose-prod/0d0ec8fd-dc9c-4b0a-85df-8bf4af0e8b8d/nodec-v1.5.0-x64.zip |
| 마코스 | x64 | https://gw.alipayobjects.com/os/enclose-prod/bc2022ef-4b88-4c12-9980-394945c9c198/nodec-v1.5.0-darwin-x64.gz |
| 리눅스 | x64 | https://gw.alipayobjects.com/os/enclose-prod/b6aa41a6-f6b5-4542-b777-06e4bc292c5e/nodec-v1.5.0-linux-x64.gz |
master 브랜치 CI가 성공할 때마다 Node.js Packer 사전 릴리스 바이너리가 자동으로 생성됩니다. 다음은 최신 불안정한 사전 릴리스 빌드입니다.
| OS | 아치. | 실행 파일 |
|---|---|---|
| 창 | x64 | https://github.com/pmq20/node-packer/releases/download/windows-x64/pre release-nodec-v140800.121803-x64.exe |
| 마코스 | x64 | https://github.com/pmq20/node-packer/releases/download/darwin-x64/pre release-nodec-v140800.121803-darwin-x64 |
| 리눅스 | x64 | https://github.com/pmq20/node-packer/releases/download/linux-x64/pre release-nodec-v140800.121803-linux-x64 |
Windows에 설치하십시오먼저 전제 조건을 설치하십시오.
그런 다음 nodec-x64.exe 를 다운로드하십시오.
선택적으로 C:Windows 또는 기타 PATH 디렉토리 아래에 넣으십시오. Visual Studio의 "X64 Native Tools 명령 프롬프트"를 열고 nodec --help 를 실행하십시오.
MACOS에 설치하십시오먼저 전제 조건을 설치하십시오.
brew install squashfsCommand Line Tools 설치해야합니다. 메뉴에서 찾을 수 있습니다 Xcode -> Preferences -> Downloadsgcc 와 make 포함 된 관련 도구 체인을 설치합니다. 그런 다음 nodec-darwin-x64 를 다운로드하십시오.
chmod +x 실행하여 실행 권한을 부여하고 ./nodec --help 실행하십시오.
최근 Travis Build에 따르면, 빌드 환경이 Xcode 11 일 때 출시가 발생한 직후 테스트 사례는 실패 할 것입니다. 현재, 실제 MACOS 배포에 영향을 미치지 않는 Travis CI 내의 다른 요인으로 인해 문제가 발생하는지 여부는 알려져 있지 않습니다.
따라서 Travis의 MacOS의 빌드 환경은 Xcode 10.2이므로 테스트 케이스를 성공적으로 실행하고 완료 할 수 있습니다.
Linux에 설치하십시오먼저 전제 조건을 설치하십시오.
sudo yum install squashfs-toolssudo apt-get install squashfs-toolsgcc 및 g++ 4.9.4 또는 최신 ORclang and clang++ 3.4.2 또는 새로운 그런 다음 nodec-linux-x64 를 다운로드하십시오.
chmod +x 실행하여 실행 권한을 부여하고 ./nodec --help 실행하십시오.
Red Hat 및 Centos 배포판의 기본 레포에는 매우 오래된 GCC / G ++ (3.8.5)가 포함되어 있으며 2018 년 2 월 15 일 현재 Ubuntu의 최신 장기 지원 (LTS)에는 비교적 업데이트 된 GCC / G ++ (7.3.0)가 포함되어 있습니다.
전제 조건 버전이 규정 된 것보다 오래된 지원되지 않은 구성을 사용할 때 컴파일이 실패 할 수있는 것으로 알려져 있습니다.
따라서 Red Hat 기반 배포판 사용자가 공식 저장소에서 외부에 GCC / G ++를 설치하는 것이 중요합니다. 우선, 다음을 볼 수 있습니다.
또한 우분투 18.04 LTS에서 컴파일 된 바이너리는 'Glibcxx_3.4.20'발견되지 않은 '관련 오류로 인해 Red Hat 7 기반 배포판 (Centos 포함)에서 작동하지 않는 것으로 알려져 있습니다. 그러나 Red Hat 또는 Centos 7에서 편집 된 바이너리는 내 내부 실험을 기반으로 Ubuntu 18.04 LT와 함께 작동하는 것으로 알려져 있습니다.
그러나 Binaries 유통 업체는 Linux 용 2 버전을 컴파일하는 것이 좋습니다. 여기서 하나는 Rhel 기반을 제공하고 다른 하나는 Ubuntu 기반을위한 2 가지 버전을 컴파일해야합니다.
최근 Travis Build에 따르면 Linux는 NODEC-1.6.0-10.16.0 (node.js 10.16.0) 이후 빌드에 실패했습니다. 근본 원인은 아직 결정되지 않았으며 마지막으로 알려진 좋은 빌드는 10.15.3으로 여기에서 다운로드 할 수 있습니다 : https://github.com/slee047/node-packer/releases/tag/1.6.0-10.15.3-1
이 문제는 여기에서 찾을 수 있습니다 : https://github.com/slee047/node-packer/issues/11
참고 :이 GZ 파일 (NODEC-DARWIN-X64.GZ)에는 구식 버전의 NODEC (NODE.JS 8.3.0이 포함 된 NODEC 1.5.0)가 포함되어 있습니다. 원래 관리자는이 리포트를 단일 실행 파일로 빌드하는 방법을 지정하지 않았으므로 최신 버전은 소스 코드에서만 직접 실행할 수 있습니다.
nodec [OPTION]... [ENTRANCE]
--current Uses the current Node.js release
--lts Uses the LTS Node.js release
-r, --root=DIR Specifies the path to the root of the application
--output=FILE Specifies the path of the output file
-d, --tmpdir=DIR Specifies the directory for temporary files
--clean-tmpdir Cleans all temporary files that were generated last time
--keep-tmpdir Keeps all temporary files that were generated last time
--make-args=ARGS Passes extra arguments to make
--vcbuild-args=ARGS Passes extra arguments to vcbuild.bat
-n, --npm=FILE Specifies the path of npm
--skip-npm-install Skips the npm install process
--debug Enables debug mode
-o, --dest-os=OS Specifies the destination operating system (enum: win mac solaris freebsd openbsd linux android aix)
-a, --dest-arch=ARCH Specifies the destination CPU architecture (enum: arm arm64 ia32 mips mipsel ppc ppc64 x32 x64 x86 s390 s390x)
--quiet Enables quiet mode
-v, --version Prints the version of nodec and exit
-h, --help Prints this help and exit
참고 : 입구가 제공되지 않으면 단일 원시 Node.js 통역사 실행 파일이 생성됩니다.
참고 : 64 비트 시스템의 32 비트 Windows OS 호환 프로그램으로 컴파일하려면 X64 X32 크로스 컴파일 환경을 사용해야합니다. Visual Studio를 설치 한 후 시작 메뉴에서 찾을 수 있어야합니다. 또한 아치 정보는 node -pe process.arch 통해 감지되므로 32 비트 노드를 사용해야합니다.
git clone --depth 1 https://github.com/jashkenas/coffeescript.git
cd coffeescript
nodec bin/coffee
./a.out (or a.exe on Windows)
git clone --depth 1 https://github.com/eggjs/examples.git
cd examples/helloworld
npm install
nodec node_modules/egg-bin/bin/egg-bin.js
./a.out dev (or a.exe dev on Windows)
| 프로젝트 | 차이 |
|---|---|
| PKG | PKG는 패키지 파일에 액세스하기 위해 fs.* PKG는 JSON을 사용하여 포장 파일을 저장하는 반면 Node.js Packer는보다 정교하고 널리 사용되는 스쿼시를 데이터 구조로 사용합니다. |
| enclosejs | enclosejs는 패키지 파일에 대한 액세스를 5 fs.* 로만 제한하는 반면, Node.js Packer는 모든 fs.* API를 지원합니다. EncloseJS는 독점 라이센스가 있으며 Node.js Packer가 MIT 라이센스가 있고 사용자가 자유롭게 사용할 수 있으며 자유롭게 수정할 수 있습니다. |
| 넥시 | Nexe는 browserify 의 사용으로 인해 동적 require 지원하지 않지만 Node.js Packer는 require.resolve 포함한 모든 종류의 require 지원합니다. |
| ASAR | ASAR은 코드 아카이브와 실행 가능을 별도로 유지하는 동안 Node.js Packer는 모든 JavaScript 소스 코드를 Node.js 가상 머신과 연결하고 최종 제품으로 단일 실행 파일을 생성합니다. ASAR은 JSON을 사용하여 파일 정보를 저장하고 Node.js Packer는 Squashf를 사용합니다. |
| Appimage | AppImage는 SquashF를 지원하는 커널을 사용하여 Linux 만 지원하는 반면 Node.js Packer는 Kernel의 특별한 기능 요구 사항없이 Linux, MacOS 및 Windows의 세 가지 플랫폼을 모두 지원합니다. |
nodec 또한 교차 컴파일을 지원합니다. Node.js는 소스에서 구축되므로 대상 플랫폼 용 바이너리를 생산하기 위해 유효한 컴파일러를 얻으려면 툴체인을 올바르게 설정해야합니다.
Crosstool-NG 또는 원하는 다른 도구를 사용하여 쉽게 수행 할 수 있습니다.
유효한 도구 체인 빌드를 마치면 (기본적으로 제외되는 Crosstool-ng를 사용하는 경우 C ++를 활성화하는 것을 잊지 마십시오) 올바르게 컴파일 할 수 있습니다. 시스템의 기본 빌드 도구 대신 크로스 컴파일 도구 체인을 사용하는 것을 알 수 있도록 환경을 설정하십시오.
예제 (값을 조정하거나 추가 변수를 지정해야 할 수도 있음) :
export AR="x86_64-unknown-linux-gnu-ar"
export CC="x86_64-unknown-linux-gnu-gcc"
export CXX="x86_64-unknown-linux-gnu-g++"
export LINK="x86_64-unknown-linux-gnu-g++"
export CPP="x86_64-unknown-linux-gnu-gcc -E"
export LD="x86_64-unknown-linux-gnu-ld"
export AS="x86_64-unknown-linux-gnu-as"
export CCLD="ax86_64-unknown-linux-gnu-gcc ${TARGET_ARCH}"
export NM="x86_64-unknown-linux-gnu-nm"
export STRIP="x86_64-unknown-linux-gnu-strip"
export OBJCOPY="x86_64-unknown-linux-gnu-objcopy"
export RANLIB="x86_64-unknown-linux-gnu-ranlib"
export F77="x86_64-unknown-linux-gnu-g77 ${TARGET_ARCH}"
unset LIBC
#Define flags
#export CXXFLAGS="-march=armv7-a"
export LDFLAGS="-L${CSTOOLS_LIB} -Wl,-rpath-link,${CSTOOLS_LIB} -Wl,-O1 -Wl,--hash-style=gnu"
export CFLAGS="-isystem${CSTOOLS_INC} -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3"
export CPPFLAGS="-isystem${CSTOOLS_INC}"
# export CCFLAGS="-march=armv7-a"
#Tools
export CSTOOLS=/Volumes/crosstools/x86_64-unknown-linux-gnu
export CSTOOLS_INC=${CSTOOLS}/include
export CSTOOLS_LIB=${CSTOOLS}/lib
#export ARM_TARGET_LIB=$CSTOOLS_LIB
# export GYP_DEFINES="armv7=1"
#Define other things, those are not 'must' to have defined but we added
export SHELL="/bin/bash"
export TERM="screen"
export LANG="en_US.UTF-8"
export MAKE="make"
#Export the path for your system
#export HOME="/home/gioyik" #Change this one with the name of your user directory
export PATH=${CSTOOLS}/bin:/usr/arm-linux-gnueabi/bin/:$PATH
Minqi Pan et al.
MIT