-
-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NodeJS 22 issues/feedbacks tracker #87
Comments
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) |
@faulpeltz That's super! PR? 🚀 |
I would extend that also on x64 build to prevent any future issue with this :) |
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... |
Yeah definetely 😆 Also because storage nowdays doesn't cost that much, RAM and CPU does... |
Can I use this release in production now? |
@cage1618 If you are speaking about nodejs 22 I would say nope, but you can use nodejs 18/20 safely with latest release |
@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 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 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.
Running it:
|
@balisaurus does it work with others nodejs version? |
Same problem here: node:internal/modules/cjs/loader:1254 Error: Cannot find module 'C:\snapshot\appname\dist\apps\server\main.js' Node.js v22.9.0 works with -t node20-win-x64 but not node22 |
Seems that the snapshot fs doesn't work for module loading on Windows in the Node 22 patch |
@BeneRasche The window issue related to nodejs 22 should be fixed on next release, please be patient. Thanks to @faulpeltz for the patch! |
We're waiting for this, right?
Based on how often nodejs releases, I think it will be either next week or mid October |
@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 |
@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? Oh lol nvm my bad it needs a v22 release |
@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 |
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. |
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 |
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. |
pkg 5.16.0 is out now with node 20.18.0 and 22.10.0 support |
pkg-fetch probably needs an update for 22.10 binaries, too? |
@BeneRasche It's out already! |
Where? |
Someone wants to give this a try? #110 🚀 |
I tested on Mac, and got same error. I think linux is too. |
I can reproduce it on Linux, and I'm working on a fix |
Ok will be fixed on next node 22 release 🙏🏼 |
The alternative is to delete binaries from release and redo the release now |
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. |
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. |
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 |
@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 |
Hello! I don't know if I'm writing in the right topic, but let it be here.
And then I built the application from this file using pkg like this:
As a result, I found out that it is enough to add the file created with esbuild to
After that I rebuilt the application and it works well on both Linux and Win. P.S. PPS |
@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 |
@robertsLando package.json
But for some reason, with this method, the application did not work on windows. |
@robertsLando I made a minimal example that reproduces the problem - https://github.com/CodingBear-Git/test-pkg |
I've had the same issue with Windows builds just now. The binary exits with no error messaging. |
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... |
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. |
@xcjs Did you tried to add that to assets like @CodingBear-Git did?
@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. |
Just FYI, the Github Actions builds for NodeJS on Windows stopped working because the GH runner image (windows-2022) contains a VS version (17.12) which is rejected by the NodeJS build scripts (on purpose, because it causes compile errors, caused by a compiler bug) MS has acknowledged the bug and a fix is pending: |
I checked. Same problem on Mac OS. |
@robertsLando
What I'm wondering about if cross-platform works with Node SEA, because internally it seems to use the same APIs to build and load the bytecode, or if it also just falls back to the JS script.. |
@faulpeltz thanks for the detailed explanation! From what I know SEA doesn't execute bytecode directly, it generates a blob (that contains the source code plus some other bytes) to inject it to the nodejs executable but it's not compiled in bytecode. I think the only one that could answer to this is @joyeecheung (who implemented node SEA feature) but not sure if he will find the time to reply here. Another one that could probably have some hints is @igorklopov |
IIRC there was a mechanism in pkg that forces generating such a bytecode that is cross-platform (otherwise without the mechanism the bytecode is platform-specific). |
@igorklopov The bytecode generation is handled in https://github.com/yao-pkg/pkg/blob/main/lib/fabricator.ts but I don't think this file received many changes in last years also I don't see any check for cross platform there or in producer |
It was |
Oh you were speaking about patches so, anyway seems not an issue as we dropped that many patches ago and this only happens on node 22 :( |
In If there is another mechanism I don't know where it can be found - but maybe this is either just a result of a breaking change in Node 22 (or the new V8 version it uses) or maybe some new flags need to be set When looking at the produced code cache blob on Linux and Windows, the generated code is exactly the same for a small but non-working example, but the hashes for the read-only snapshots are different - if someone has an idea where these are coming from or where they are generated during build, maybe I can find out whats different |
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#49Module Loading not working with Windows- Ref fix: restore mac arm64 build pkg-fetch#46Error: Cannot find module
cc @faulpeltz
The text was updated successfully, but these errors were encountered: