Unfortunally I don't think it is that easy, I think we removed it also for compatibility problems in node build. Let's see @jesec thoughts on this

Nope. 32-bit x86 has no place in 2021.

Unfortunally I don't think it is that easy, I think we removed it also for compatibility problems in node build. Let's see @jesec thoughts on this

At least when I build for x86 it does work, see my forked repo and the actions log

Nope. 32-bit x86 has no place in 2021.

Yes if you start with a new codebase I agree, however if you have an existing codebase with over 50k lines of code it is not so easy to migrate to 64bit. So our NodeJS C++ connection has to be compiled as 32bit otherwise it won't link.

Download Metrics in 2021 ( source:

So the x86 version has been downloaded +/- 1 mil. times and x64 2mil times, so roughly 47% of the versions downloaded is 32bit and you say, no room for 32bit?

If the number would be a lot smaller I would agree with you. However it seems NodeJS 32bit is used widely.

See also #164 not working for windows

Any update on this?

Just wondering why we build for arm64 and windows and we skip all builds for x86 and Windows. Since the arm64 for Windows is still so minor.

So @jesec or @robertsLando is there a chance of reconsidering your statement?

Main reason for me is also that I can't seem to compile NodeJS in my environment and when using the created NodeJS binary from my forked repo pkg is working as should.

Since my latest PR was merged upstream I would be nice if I can actually use it in my environment, sadly it is x86 until we can do massive rewrite of our C++ codebase.

Thanks

So @jesec or @robertsLando is there a chance of reconsidering your statement?

Main reason for me is also that I can't seem to compile NodeJS in my environment and when using the created NodeJS binary from my forked repo pkg is working as should.

Since my latest PR was merged upstream I would be nice if I can actually use it in my environment, sadly it is x86 until we can do massive rewrite of our C++ codebase.

Thanks

Nope.

Eventually, you are going to make your codebase work with 64-bit, so let this be the reason to jump start the process.

If it is burdensome for you to deal with your stuff, it is equally burdensome for us to (unhappily) maintain an unnecessary platform.

I see some merits in the embedded armv7 case (https://github.com/vercel/pkg-fetch/issues/109#issuecomment-831451347) given the first arm64 cores were released around 2012. x86 is a completely different story, though. All functional x86 CPU today can run 64-bit, and 64-bit has been available since Windows 2003 days.

Note that you can choose to maintain your own set of binaries. Simply build and place them to .pkg-cache folder with built-* filenames. See https://github.com/Hypfer/pkg-fetch .

Eventually, you are going to make your codebase work with 64-bit, so let this be the reason to jump start the process.

Yes I agree, however rewriting a legacy codebase will take some years making sure all code works as should. Specially if your old codebase is full of old C++ and C code. Hence if your program is made in 20 years with Visual C++ then you have something ahead of you. Where the benefits of rewriting the code are small. The program doesn't use a huge amount of memory so going for x64 doesn't bring any performance boost or so.

If it is burdensome for you to deal with your stuff, it is equally burdensome for us to (unhappily) maintain an unnecessary platform.

I would agree if you can show me what the actual problem is with adding an extra git action. It does work as should, it is just the LTS release.

I fully disagree with you saying that x86 is unnecessary platform on Windows. If you would check for example Program Files (x86) and Program Files on a default Windows 10 install. On my business laptop the size of the x86 folder is 15gb whereas the x64 is 3gb. This shows to me that the majority of software on Windows is still 32bit. See this example for Microsoft Office and the struggle for x64

My observation of 32bits programs on Windows matches with the number of downloads of NodeJS for 32bit Windows. Yes it is less however still 47% of the number of downloads. Downloading NodeJS 32bit really takes some extra steps, since the default one is pointing out to x64. So certainly an huge amount of people take that extra step to download the 32bit version on purpose.

How can a mainstream platform Windows x86 be burdensome? I would agree if NodeJS drops support for x86 on Windows.

I see some merits in the embedded armv7 case (#109 (comment)) given the first arm64 cores were released around 2012. x86 is a completely different story, though. All functional x86 CPU today can run 64-bit, and 64-bit has been available since Windows 2003 days.

It is not a problem that I cannot run a x64 program, however if you want to link Node-API with your own C++ program both have to be in the same architecture. The same is for several other npm packages which compile in to a .node file and are also not working at x64.

Note that you can choose to maintain your own set of binaries. Simply build and place them to .pkg-cache folder with built-* filenames. See https://github.com/Hypfer/pkg-fetch .

Yes I will maintain a fork if this is the view of the maintainers. Imho the view that x86 for Windows is history is short sighted. Hence I struggle to accept that statement, since there are a lot of observations that x86 for Windows is not dead (yet). And as you could see I'm not the only one struggling with your statement.

Thanks for the explanation @jesec! I'm going to close this as a decision has been made 🙏