NodeJS 22/24 issues/feedbacks tracker

@faulpeltz

NodeJS 22 support has been added starting from pkg 5.14.0 but many things have changed on NodeJS source and so also on our patch file so it needs some tests. Use this issue to submit your feedbacks and issues

KNOWN ISSUES:

MacOS ARM64 not available: feat: add Node 22 patch (#45) (by @faulpeltz) pkg-fetch#45. Reason is that ATM no github runner is able to produce a valid binary without going out of RAM or exceeding 6h max build time. Fixed in 5.14.1 - Ref fix: node 22 module filename resolution in win32 (#49) by @faulpeltz pkg-fetch#49
~~Module Loading not working with Windows Error: Cannot find module~~ - Ref fix: restore mac arm64 build pkg-fetch#46
Cross OS compilation of node 22 has issues with Windows: NodeJS 22/24 issues/feedbacks tracker #87 (comment). The build succeeds but when running the binary it exits without any output.
- Actual workaround: use --public flag (to include sources)
Cross compilation from and to macOS (without --public) doesnt work since Node 22 (Cross-compilation from macOS to Linux on arm64 broken on >=22 #181)

cc @faulpeltz

I managed to complete a Node 22 build with macos arm64 after removing the android SDK (the change from the node/build repo), and then also removed the iOS simulator cache (which is nearly 50GB)

yao-pkg/pkg-fetch@main...faulpeltz:pkg-fetch:main#diff-a1654f4357833dfc4d0c6a8d39c2e3ee30ceea604c29238846903993434ab384R93

@faulpeltz

@faulpeltz That's super! PR? 🚀

I would extend that also on x64 build to prevent any future issue with this :)

@faulpeltz

@faulpeltz That's super! PR? 🚀

I'm trying to find out why the x64 macos build on -13 is so fragile, I had it crash or timeout multiple times. But the cleanup seems not necessary for now because it has ~200GB free disk space, and I assume it will imrpove in the future 🤷‍♂️

I really don't want to complain about free Apple build infrastructure, but 14GB of free disk space is a bit of a stretch...

I really don't want to complain about free Apple build infrastructure, but 14GB of free disk space is a bit of a stretch...

Yeah definetely 😆 Also because storage nowdays doesn't cost that much, RAM and CPU does...

Can I use this release in production now?

@cage1618

@cage1618 If you are speaking about nodejs 22 I would say nope, but you can use nodejs 18/20 safely with latest release

@robertsLando

@robertsLando The Node 22 patch applies to the just-released 22.9 version without problems and all builds went through

In this release they disabled Maglev (one of the JIT compilers) because of reported crashes
https://github.com/nodejs/node/releases/tag/v22.9.0

So random crashes might be caused by latent Node 22 issues before 22.9, might make sense to bump the Node 22 version (but not urgent)

@faulpeltz

@faulpeltz thanks for the info, I have an action to automatically create the patch, let me run it 🚀

I have created a workflow that automatically check for new nodejs versions: https://github.com/yao-pkg/pkg-fetch/actions/workflows/check-latest-node.yml

release 5.15.0 is stable now?

Using 5.15.0 to use latest nodejs 22 doesn't seem to work for my project.
I create a simple test code with a single file writing hello to console:

pkg --debug hello.js --targets node22-win-x64
> pkg@5.15.0
(node:27328) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
> [debug] Bytecode of D:\temp\testnode\hello.js is added to queue.
> [debug] Stat info of D:\temp\testnode\hello.js is added to queue.
> [debug] Directory D:\temp\testnode is added to queue.
> [debug] Stat info of D:\temp\testnode is added to queue.
> [debug] Directory D:\temp is added to queue.
> [debug] Stat info of D:\temp is added to queue.
> [debug] Directory D:\ is added to queue.
> [debug] Stat info of D:\ is added to queue.
> [debug] Deleting record file : D:\
> [debug] The file was included as bytecode (no sources)
  D:\temp\testnode\hello.js
> [debug] The file was included as bytecode (no sources)
  D:\temp\testnode\hello.js
> [debug] files & folders deduped =
  hello.js
> [debug] The directory files list was included (1 item)
  D:\temp\testnode
> [debug] The directory files list was included (1 item)
  D:\temp\testnode
> [debug] files & folders deduped =
  testnode
> [debug] The directory files list was included (1 item)
  D:\temp
> [debug] The directory files list was included (1 item)
  D:\temp
> [debug] Targets:
  [
  {
    "nodeRange": "node22",
    "platform": "win",
    "arch": "x64",
    "output": "d:\\temp\\testnode\\hello.exe",
    "forceBuild": false,
    "fabricator": {
      "nodeRange": "node22",
      "platform": "win",
      "arch": "x64",
      "binaryPath": "C:\\Users\\tekno\\.pkg-cache\\v3.5\\fetched-v22.9.0-win-x64"
    },
    "binaryPath": "C:\\Users\\tekno\\.pkg-cache\\v3.5\\fetched-v22.9.0-win-x64"
  }
]

Running it:

hello.exe
------------------------------- virtual file system
C:\snapshot
  testnode                                29 Bytes
    hello.js                              29 Bytes
Total size =  29 Bytes
node:internal/modules/cjs/loader:1254
  throw err;
  ^

Error: Cannot find module 'C:\snapshot\testnode\hello.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1251:15)
    at Function._resolveFilename (pkg/prelude/bootstrap.js:1955:46)
    at Module._load (node:internal/modules/cjs/loader:1077:27)
    at Function.runMain (pkg/prelude/bootstrap.js:1983:12)
    at node:internal/main/run_main_module:30:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v22.9.0

@balisaurus

@balisaurus does it work with others nodejs version?

@faulpeltz

I reverted my prior comment; I'm still having issues with node@22 with my app. I've tried other more complicated bpkg apps that are still simplified (I'm using a (async () => {})(); call in my app that I thought was causing an issue; it's not) and switching to --public and those both work. There's definitely still an issue.

I've tried recompiling @yao-pkg/pkg-fetch uncommenting the print statement that @faulpeltz added to look at the checksum but I get an error when I run the packaged binary saying it can't find the script, like it didn't get inserted to the node binary. I'm reverting back to node20 for my app but happy to try some things if you have any ideas on how to debug pkg-fetch further.

I don't really have good repro steps unfortunately as it only reproduces with my private code thusfar.

Info: Confirmed cross compiling a node22-alpine-x64 build on Windows (Server 2025) fails. (version 6.10.1)

It generates the discussed 'no output' executable

Linux cross-compiling from amd64 to arm64 is broken since some a few versions, at least for node-22 - node-20 is still working.
From my testing, on 6.10.1 it was still working, but on 6.14.1 I see broken binaries.

@Niek

@Niek What's the error you get?

i too have the cross-compiling problem (mac with target windows), only with node 22 and not with 20, build without errors, but running the exe i get exit code 4, and i DO have some output, until the crash.
Maybe those without output it's just because they dont' print anything before the crash.
the problem goes away if i target windows on a windows VM.

additional note: no problem with node 24, only 22

@faulpeltz

@faulpeltz Any clue?

🚀 Enhanced SEA Mode — A new way to package your Node.js apps

We've been working on a major new feature in #229 that we're excited to share: Enhanced SEA (Single Executable Application) mode with full dependency walking and VFS support.

✨ What's new

Running pkg . --sea with a package.json input now automatically uses a full packaging pipeline powered by Node.js official Single Executable Applications API and @platformatic/vfs for transparent filesystem virtualization.

💡 Why this matters

🔓 No more patched Node.js binaries — Enhanced SEA uses the official node:sea API. No custom binary patches, no maintaining fork-specific diffs against upstream Node.js. This means better compatibility with future Node.js releases out of the box
📦 Native ESM support without bundling — ESM projects work as-is. No ESM-to-CJS transformation, no bundler required. Just point pkg at your package.json and it handles everything
⚡ Faster builds — No V8 bytecode compilation step (which spawns a Node.js process per file). SEA builds are significantly faster, especially for large projects
🧵 Worker thread support — Workers spawned with /snapshot/... paths automatically get VFS hooks injected
🔮 Future-proof — Built on official Node.js APIs (node:sea, with migration path to node:vfs when nodejs/node#61478 lands). As Node.js improves SEA support, pkg benefits automatically

⚠️ Trade-offs to be aware of

🔍 No source code protection — SEA mode stores source code as plaintext inside the executable. There is no sourceless equivalent in the Node.js SEA design. If you need code protection, stick with traditional pkg mode (V8 bytecode) or pre-process your code with an obfuscator
📏 No compression — SEA assets are stored uncompressed, so executables will be larger than traditional pkg output for the same project
🟢 Node >= 22 required — Both the build host and target must be Node.js 22+

📊 Performance

Benchmarked against zwave-js-ui (~1,776 source files):

Method	Build Time	Binary Size	Startup Time
Standard PKG (with bundle)	16.5s	111 MB	261ms
SEA with bundle	10.1s	145 MB	381ms
SEA without bundle	39.9s	377 MB	711ms

SEA without a bundler is now viable for production — 711ms startup handling ESM natively with zero bundler configuration. For startup-critical apps, SEA + a bundler (esbuild, etc.) gets you to 381ms. Full benchmark details and perf profiling data in this comment.

🧪 Try it out

pkg . --sea                    # enhanced mode (auto-detected with package.json)
pkg . --sea -t node24-linux    # target specific platform

Feedback welcome on #229! 🙌

@robertsLando

@Niek What's the error you get?

@robertsLando No error, just an immediate exit with error code 4. I cross-compiled from a throwaway docker run --platform=linux/amd64 node:25-bookworm ... pkg . --targets node22-linux-arm64, then ran the binary in docker run --platform=linux/arm64

I can confirm that node-24 is working correctly though, so we have switched to that.

docs: clarify cross-compile support and Node 22 regression

docs: host documentation on GitHub Pages with VitePress (#234)

New docs are live: https://yao-pkg.github.io/pkg/ 🎉

fix: fall back to source on bytecode fabrication failure

feat: add --fallback-to-source flag for bytecode compilation failures

feat: add --fallback-to-source flag for bytecode failures (#246)

Navigation Menu

Repository navigation

NodeJS 22/24 issues/feedbacks tracker #87

86 remaining items

🚀 Enhanced SEA Mode — A new way to package your Node.js apps

✨ What's new

💡 Why this matters

⚠️ Trade-offs to be aware of

📊 Performance

🧪 Try it out

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NodeJS 22/24 issues/feedbacks tracker #87

Description

Activity

faulpeltz commented on Sep 11, 2024

robertsLando commented on Sep 11, 2024

robertsLando commented on Sep 11, 2024

faulpeltz commented on Sep 11, 2024

robertsLando commented on Sep 11, 2024

cage1618 commented on Sep 18, 2024

robertsLando commented on Sep 18, 2024

faulpeltz commented on Sep 18, 2024

robertsLando commented on Sep 18, 2024

robertsLando commented on Sep 19, 2024

cage1618 commented on Sep 21, 2024

balisaurus commented on Sep 23, 2024

robertsLando commented on Sep 23, 2024

86 remaining items

mikeseese commented on Oct 20, 2025

CodeRunsTheWorld commented on Nov 10, 2025

Niek commented on Feb 24, 2026

robertsLando commented on Feb 24, 2026

rejetto commented on Mar 1, 2026

rejetto commented on Mar 3, 2026

robertsLando commented on Mar 3, 2026

robertsLando commented on Apr 8, 2026

🚀 Enhanced SEA Mode — A new way to package your Node.js apps

✨ What's new

💡 Why this matters

⚠️ Trade-offs to be aware of

📊 Performance

🧪 Try it out

Niek commented on Apr 10, 2026

robertsLando commented on Apr 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions