NodeJS 22 issues/feedbacks tracker

[robertsLando]

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: https://github.com/yao-pkg/pkg-fetch/pull/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 https://github.com/yao-pkg/pkg-fetch/pull/49
• ~Module Loading not working with Windows Error: Cannot find module~ - Ref https://github.com/yao-pkg/pkg-fetch/pull/46

cc @faulpeltz

[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)

https://github.com/yao-pkg/pkg-fetch/compare/main...faulpeltz:pkg-fetch:main#diff-a1654f4357833dfc4d0c6a8d39c2e3ee30ceea604c29238846903993434ab384R93

[robertsLando]

@faulpeltz That's super! PR? 🚀

[robertsLando]

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 :man_shrugging:

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

[robertsLando]

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...

[cage1618]

Can I use this release in production now?

[robertsLando]

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

[faulpeltz]

@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)

[robertsLando]

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

[robertsLando]

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

[cage1618]

release 5.15.0 is stable now?

[balisaurus]

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

[robertsLando]

@balisaurus does it work with others nodejs version?

[BeneRasche]

Same problem here:

node:internal/modules/cjs/loader:1254 throw err; ^

Error: Cannot find module 'C:\snapshot\appname\dist\apps\server\main.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

---

works with -t node20-win-x64 but not node22

[faulpeltz]

Seems that the snapshot fs doesn't work for module loading on Windows in the Node 22 patch

[robertsLando]

@BeneRasche The window issue related to nodejs 22 should be fixed on next release, please be patient. Thanks to @faulpeltz for the patch!

[thisjt]

We're waiting for this, right?

@faulpeltz Unfortunately we need to wait a new nodejs 22 release in order to test this as I have no way with current workflows to force build a specific version, I need to implement this

Based on how often nodejs releases, I think it will be either next week or mid October

[robertsLando]

@thisjt yep, I'm sorry!

Problem is that actually I cannot release patches for nodejs patches as them would become broke for actual pkg versions as the shas are shipped with npm so updating them would change them and work only for latest vesrsions. I already have a workflow that runs every day at midnight and opens a PR when a new patch is available

[thisjt]

@robertsLando nodejs had a release 4 days ago. I think it's time to patch 😬 let's gooo- or does it need to have a v22 release? https://github.com/nodejs/node/releases/tag/v20.18.0

---

Oh lol nvm my bad it needs a v22 release

[robertsLando]

@thisjt thanks for letting me know! Seems my automated workflows picked up it correctly 4 days ago but the patches do not apply cleanly, let me try to fix this

https://github.com/yao-pkg/pkg-fetch/actions/runs/11171900799/job/31057489528

BTW seems only node 20 has a new release for now

[thisjt]

node v22.10 is finally out! https://github.com/nodejs/node/releases/tag/v22.10.0

And with that node v23 is also out, hoping that we will also be supporting this. Not in a hurry tho, we're not sure yet on how stable v23 is.

[dingiyan]

I often follow this library and hope to keep up with the latest version of Node.js. This morning, I tested the v22 version, but it is not yet available. I hope excellent authors can continue to follow up and look forward to the latest available v22 version. Finally, I would like to thank the contributors of yao-pkg for their hard work

[robertsLando]

New version is coming soon. The average delay I would like to keep between nodejs releases and pkg support for them is around 1 week, it depends on how many breaks there are on patches.

[robertsLando]

pkg 5.16.0 is out now with node 20.18.0 and 22.10.0 support

[BeneRasche]

pkg-fetch probably needs an update for 22.10 binaries, too?

[robertsLando]

@BeneRasche It's out already!

[BeneRasche]

@BeneRasche It's out already!

Where?

https://github.com/yao-pkg/pkg-fetch/releases

[robertsLando]

[dingiyan]

Hello, @robertsLando I found a bug on node v22. This issue seems to be caused by the inconsistent behavior of pkg's require for example, the streamx package was required

// index.js
const sss = require("streamx")

console.log(sss.isStreamx);

on node v22, I use node index.js , and the result is ok.

on pkg build (22.10 version, target is windows), the exe excuted but print an error, like this:

D:\study\demo\pkg-22>index.exe
pkg/prelude/bootstrap.js:1872
      throw error;
      ^

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in C:\snapshot\pkg-22\node_modules\streamx\package.json
    at exportsNotFound (node:internal/modules/esm/resolve:296:10)
    at packageExportsResolve (node:internal/modules/esm/resolve:586:13)
    at resolveExports (node:internal/modules/cjs/loader:644:36)
    at Function._findPath (node:internal/modules/cjs/loader:752:31)
    at Function.<anonymous> (node:internal/modules/cjs/loader:1239:27)
    at Function._resolveFilename (pkg/prelude/bootstrap.js:1947:44)
    at Function._load (node:internal/modules/cjs/loader:1079:27)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Module.<anonymous> (node:internal/modules/cjs/loader:1344:12) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

Node.js v22.10.0

I found, the steramx package has main field for export the package entry, but not exports field. and the node22 changed the require method for support require(esm)

I think, the problem is pkg's require method not equal to node22's require method. It's like the pkg's require take for the module is esm (but it's a cjs module ) and throws error.

please check it, thank you.

[robertsLando]

@dingiyan thanks for your detailed issue! Could you tell me if that's just related to 22-win? Are you also able to reproduce it with 22-linux? I think this may be related to:

https://github.com/yao-pkg/pkg-fetch/blob/main/patches/node.v22.10.0.cpp.patch#L344-L346

@faulpeltz what do you think?

There is also a reference to https://github.com/yao-pkg/pkg/blob/main/prelude/bootstrap.js#L1942

But I don't think the issue is there

[robertsLando]

Someone wants to give this a try? https://github.com/yao-pkg/pkg/pull/110 🚀

[dingiyan]

@dingiyan thanks for your detailed issue! Could you tell me if that's just related to 22-win? Are you also able to reproduce it with 22-linux? I think this may be related to:

https://github.com/yao-pkg/pkg-fetch/blob/main/patches/node.v22.10.0.cpp.patch#L344-L346

@faulpeltz what do you think?

There is also a reference to https://github.com/yao-pkg/pkg/blob/main/prelude/bootstrap.js#L1942

But I don't think the issue is there

I tested on Mac, and got same error. I think linux is too. I think the issue point is node.v22.10.0.cpp.patch

[faulpeltz]

@dingiyan thanks for your detailed issue! Could you tell me if that's just related to 22-win? Are you also able to reproduce it with 22-linux? I think this may be related to:

https://github.com/yao-pkg/pkg-fetch/blob/main/patches/node.v22.10.0.cpp.patch#L344-L346

@faulpeltz what do you think?

There is also a reference to https://github.com/yao-pkg/pkg/blob/main/prelude/bootstrap.js#L1942

But I don't think the issue is there

I can reproduce it on Linux, and I'm working on a fix

[robertsLando]

Ok will be fixed on next node 22 release 🙏🏼

[robertsLando]

The alternative is to delete binaries from release and redo the release now

[faulpeltz]

Would it be possible to create a new GH release for each pkg fetch release and keep the new binaries there?

[robertsLando]

Would it be possible to create a new GH release for each pkg fetch release and keep the new binaries there?

That's actually not possible as pkg downloads assets from pkg-fetch GH releases.

[thisjt]

Maybe we can add a feature wherein we can specifically target a pkg-fetch release instead of getting the latest one for that specific node version. That way we'll have some flexibility on what pkg-fetch release we can specifically target instead of always getting the latest one.

I'd need to look into how the entire pkg-fetch works as a whole though so I might need a bit of schooling as to why this is, or why this is not possible or viable. Would be nice to have this feature so that we can roll out hotfixes instead of waiting for a new node release every time we need to fix an issue.

[robertsLando]

See: https://github.com/yao-pkg/pkg-fetch/blob/main/DEVELOPMENT.md

[dingiyan]

Hello, I view the 22.11.0 versions was released on pkg-fetch, but I got version 22.10.0 when I use pkg build. I test the @yao-pkg/pkg on 5.16.1 and 6.0.1

[robertsLando]

@dingiyan Because I triggered the workflow to build nodejs patches but then completely forgot to create a new release (workflow takes 4/5hours to complete). It's out now: 6.1.0

[CodingBear-Git]

Hello! I don't know if I'm writing in the right topic, but let it be here. When trying to compile an application into an executable file, I had a situation where the application was compiled perfectly for targets: latest-linux-x64 and latest-win-x64. Then on Linux everything started and worked fine, but when trying to run on Win, the application did NOT work and did NOT give any errors. I built the application like this: first, I built the entire source code with esbuild into 1 file, like this:

{
    entryPoints: ["./src/app.ts"],
    bundle: true,
    platform: "node",
    keepNames: true,
    minify: true,
    outfile: "./dist/app-bundle.js"
}

And then I built the application from this file using pkg like this:

"pkg": {
    "assets": [],
    "ignore": [],
    "outputPath": "dist/bin",
    "targets": [
        "latest-win-x64",
        "latest-linux-x64"
    ]
}

As a result, I found out that it is enough to add the file created with esbuild to assets. Like this:

"assets": [
    "dist/app-bundle.js"
]

After that I rebuilt the application and it works well on both Linux and Win. With this message I want to say that maybe somewhere in the readme it is worth writing that when using esbuild you need to explicitly specify "assets": ["dist/app-bundle.js" ] in config pkg.

P.S. At the same time, for targets node20-win-x64 everything was assembled and worked without adding anything to assets.

PPS @robertsLando Thanks for all the work you do to maintain this package!

[robertsLando]

@CodingBear-Git what is the pkg command you run to package your application? Because it should have bin property set to dist/app-bundle.js

[CodingBear-Git]

@robertsLando pkg ./dist/app-bundle.js --config package.json

package.json

"pkg": {
    "assets": [],
    "ignore": [],
    "outputPath": "dist/bin",
    "targets": [
      "latest-win-x64",
      "latest-linux-x64",
      "latest-mac-x64"
    ]
  }

But for some reason, with this method, the application did not work on windows.

[CodingBear-Git]

@robertsLando I made a minimal example that reproduces the problem - https://github.com/CodingBear-Git/test-pkg

[xcjs]

@robertsLando pkg ./dist/app-bundle.js --config package.json

package.json

"pkg": {
    "assets": [],
    "ignore": [],
    "outputPath": "dist/bin",
    "targets": [
      "latest-win-x64",
      "latest-linux-x64",
      "latest-mac-x64"
    ]
  }

But for some reason, with this method, the application did not work on windows.

I've had the same issue with Windows builds just now. The binary exits with no error messaging.

[faulpeltz]

I can reproduce this with the Windows build only, it works when including the sources with "--public" (both with and without bytecode), so something is breaking when the sources are not found, but since the other platforms are working...

[faulpeltz]

Also, when running pkg on a Windows box the windows build works fine, and building the linux binary on the Windows box also results in a broken binary not working on linux anymore. So it looks like the bytecode might be incompatible/different depending on the build platform?

[robertsLando]

I've had the same issue with Windows builds just now. The binary exits with no error messaging.

@xcjs Did you tried to add that to assets like @CodingBear-Git did?

So it looks like the bytecode might be incompatible/different depending on the build platform?

@faulpeltz bytecode is always different I mean the sha of bytecode always changes on each run as it's not deterministic. ATM the bytecode is created by https://github.com/yao-pkg/pkg/blob/main/lib/fabricator.ts but sincerely I have no clue what could be broken here

[xcjs]

I've had the same issue with Windows builds just now. The binary exits with no error messaging.

@xcjs Did you tried to add that to assets like @CodingBear-Git did?

So it looks like the bytecode might be incompatible/different depending on the build platform?

@faulpeltz bytecode is always different I mean the sha of bytecode always changes on each run as it's not deterministic. ATM the bytecode is created by https://github.com/yao-pkg/pkg/blob/main/lib/fabricator.ts but sincerely I have no clue what could be broken here

I haven't tried to add assets. The same build works with Node 20, though without assets.