Did anyone successfully package a NestJS app with pkg and SEA? #236
-
|
Hi, did anyone manage to package a NestJS app with pkg and SEA? If so, please let me know :) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 20 replies
-
|
@julianpoemp could you tell me what kind of issues you faced doing this? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the fast answer! I'm getting an segmentation fault error. I'll post a minimal non-working example for reproduction |
Beta Was this translation helpful? Give feedback.
-
|
I created a minimal non-working example repository: https://github.com/julianpoemp/yao-pkg-nestjs-sea-example . The example contains just a fresh initialized NestJS project. Results: PKG without SEABuildable and executable. PKG with SEABuildable. Not executable. Build OutputRun OutputPKG with SEA EnhancedNot buildable. Output |
Beta Was this translation helpful? Give feedback.
-
|
The issue is you have put yao-pkg/pkg into dependencies, this means it ends up in the package and the package itself contains the string |
Beta Was this translation helpful? Give feedback.
-
|
thanks, I changed the dependency to dev dependency. Now it's buildable with SEA Enhanced, but not executable: same situation with normal SEA, too... Edit: I tried the same package scripts on Windows, too. It's buildable, but on execution I get no result. Even with a simple NodeJS script containing a one liner of console.log. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @julianpoemp, thanks for the minimal repro — I was able to reproduce and track down the root cause. Summary of findings and a fix in #247: Your two issues1. 2. Segfault on macOS arm64 after the devDeps fix — root cause is in pkg's SEA pipeline, specifically Fix in #247: split the SEA ad-hoc-sign path into its own helper that skips the Note on vanilla
|
Beta Was this translation helpful? Give feedback.
-
|
Replying to your Mail from 20.04.26 16:04 MacOS ARM64 17:45Testing packaging on MacOS ARMStepsAs described I did the following steps:
Output
Output <After 2-3 Seconds Nothing>
Output
Output Reading binary by Daniel on MacOS ARM
Output
Output |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @julianpoemp — the diagnostics are gold. Two findings: 1. Signatures are both valid — codesign is cleared of suspicionYour ldid-signed build has a proper 2. The actual smoking gun: your SEA blob is ~55 KB larger than mine on the same source
Same The most common culprit here is macOS filesystem noise:
Could you run these diagnostics?A. Is the ldid-signed build actually executable? You stopped after the B. Inspect macOS-specific noise in the repro's cd ~/repos/yao-pkg-nestjs-sea-example
find node_modules -name '.DS_Store' | wc -l
find node_modules -name '._*' | wc -l
du -ch $(find node_modules -name '.DS_Store' -o -name '._*') 2>/dev/null | tail -1
find node_modules -name '*.node' | head -20C. Native stack trace from lldb — this is the only thing that'll tell us why Node crashes parsing the blob (missing asset? malformed manifest? header overflow?): lldb ./dist/sea-enhanced/server-macos-arm64
(lldb) run
# wait for the crash
(lldb) bt all
(lldb) quitPaste the D. If (B) shows any find node_modules -name '.DS_Store' -delete
find node_modules -name '._*' -delete
# rebuild
node ../pkg/lib-es5/bin.js --sea . -t node22-macos-arm64
./dist/sea-enhanced/server-macos-arm64If that boots cleanly, I'll push a filter to pkg's walker to always skip those on all hosts — safe change, long overdue. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately it's not working... it's a really strange issue :/
Output:
|
Beta Was this translation helpful? Give feedback.
-
|
Julian, that lldb trace is the answer. 🎯 The crash is inside Translation: Node 22.22.2 cannot parse the SEA blob header that was embedded into your binary. The postject injection is fine (we confirmed via The Root cause: blob generator version mismatchpkg generates the SEA prep blob by invoking
Your targets are My build worked because my host Node was 22.22.1 and my generated blob happens to be backward-compatible with the 22.22.2 reader. Yours is on a version where it isn't. Two things I need from you1. Host Node version: node --version
which node2. Quick verification — force pkg to use the downloaded 22.22.2 as the generator too: The cleanest test is to make your local Node match the target exactly: nvm install 22.22.2
nvm use 22.22.2
node --version # must print v22.22.2
cd ~/repos/yao-pkg-nestjs-sea-example
node ../pkg/lib-es5/bin.js --sea . -t node22-macos-arm64
./dist/sea-enhanced/server-macos-arm64If If this boots cleanly, the root cause is confirmed, and I'll push the real fix to #247: always use the downloaded target Node as the blob generator when the host platform/arch matches the target (we already downloaded it and it's guaranteed runnable), eliminating the version-skew footgun entirely. Cross-platform builds (Linux host → Mac target) still fall back to |
Beta Was this translation helpful? Give feedback.
-
|
I installed node v22.22.2 and ...... IT WORKS! AWESOME! 🎉 Thank you! 
|
Beta Was this translation helpful? Give feedback.
-
|
Reproduced and fixed locally. 🎉 I replayed the scenario on my Linux x64 box using nvm to swap host Node versions, against the same NestJS repro, same
And the gdb stack trace on my crash matches yours frame-for-frame: So the root cause is confirmed: the SEA prep-blob layout was changed somewhere between Node 22.18 and 22.20, and pkg's old The fix — now in PR #247 (commit
|
Beta Was this translation helpful? Give feedback.
-
|
I can confirm it works with v22.18.0 on my Mac ARM :D How are you able to respond so fast and solve issues so fast? Are you using a kind of AI? :) |
Beta Was this translation helpful? Give feedback.
-
Is there still someone doing development without it? 😆 |
Beta Was this translation helpful? Give feedback.
-
|
6.18.2 ships the fix 🎉 |
Beta Was this translation helpful? Give feedback.
Julian, that lldb trace is the answer. 🎯
The crash is inside
FindSingleExecutableResource— that's the SEA blob header parser, running before V8 is even initialized.ReadArithmetic<unsigned long>is reading an 8-byte length field from the blob and getting0x936c6f6734a0218fback — pure garbage, then used as a pointer →EXC_BAD_ACCESS.Translation: Node 22.22.2 cannot parse the SEA blob header tha…