Node js не ставится на windows 7

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

Partially reverted in #33176 (in Node.js 14.5.0). The msi installer is still blocked on Windows 7 but the 7z/zip and/or exe downloads are not if an environment variable is set.

Support for Windows 7 was removed in #31954 (for Node.js v14.0.0)

Partially reverted in #33176 (in Node.js 14.5.0). The msi installer is still blocked on Windows 7 but the 7z/zip and/or exe downloads are not if an environment variable is set.

Yet the environment variable does literally nothing after it’s set

Yet the environment variable does literally nothing after it’s set

Close and re-open the command window.

Does the installer check if the Win7 platform is still supported through Microsoft’s extended support that is sold through the end of 2023?
Since cygwin is a POSIX/Linuxish compatible platform, does node.js support run on Cygwin?

Add Windows support to the 14 branch of the node!

Because of this limitation, half of the projects cannot be supported if the developer’s computer has a seven.

As far as I can tell, this is essentially just a whim of the developers — «let’s stop supporting this junk», despite the fact that people continue to use it, and there are no killerfits here, which could be expected in the 14th version due to the termination of support.

I duplicate my post also in this thread: #38761

Sorry if this looks intrusive, but because of this, I am now facing a situation in which I, apparently, have to install a virtual machine to run a new Windows under it, simply because I cannot (and do not want to) update the OS for a thousand reasons, but for work I need Win and NodeJS not lower than 14th, аnd this is real ridiculous situation. Therefore, I want the developers to pay attention to the problem. Thanks.

Afaik the latest node is able to work on 7 by changing a single function and setting the variable.

Does the installer check if the Win7 platform is still supported through Microsoft’s extended support that is sold through the end of 2023?

@Astara I don’t think so. It’s all open-source, so feel free to propose changes through PRs or recompile with your own logic. There are alternative installation methods that do not require using the MSI as well.

Add Windows support to the 14 branch of the node!

@Psychosynthesis the latest 14.x releases include this logic:

Is this not working for you, even after setting the NODE_SKIP_PLATFORM_CHECK environment variable as documented for Node.js 14? As discussed here and elsewhere, the MSI might not be working, but other installation mechanisms should.

Why even add more code that wastes cycles and makes the program bigger? If it breaks, it breaks. If it works, it works.

@tniessen v.14.19.0 was not working even if i set the NODE_SKIP_PLATFORM_CHECK. However, I succeeded to install version v.14.17.6 and it work for me (at least for now).

Previously, I installed the latest available 13.x version, and then simply replaced its files with files from the fourteenth zip archive.
I don’t know if it’s possible to skip the step with the 13th version — I just checked if my project would work on it.

This, of course, is better than nothing, but it will be sad if the developers of any of the packages once again decide to update their dependencies without much sense (as in this case, they obviously did in typescript-eslint v.5.3).

soo much trouble caused by rushing drop support of something that is totally capable to run node… for no gains other than say that some newer function call that is just a convenient way (or may more linux like) way of doing what was already possible, instead of wrap such functionality on a function that does not need to be changed ever again, that would implement the same functionality even if in a slight less performant way… its lol

Why even add more code that wastes cycles and makes the program bigger? If it breaks, it breaks. If it works, it works.

@K4sum1 Why do guard rails exist that waste metal and cost money? Because they deter from entering dangerous areas. Node.js makes no security guarantees on Windows 7. You can still climb over guard rails and you can still use Node.js on Windows 7 by simply setting NODE_SKIP_PLATFORM_CHECK as documented. But it also means you are on your own.

v.14.19.0 was not working even if i set the NODE_SKIP_PLATFORM_CHECK

@Psychosynthesis If you can reproduce that behavior, please feel free to report it as a bug and/or send a PR to fix it.

soo much trouble caused by rushing drop support of something that is totally capable to run node… for no gains other than say that some newer function call that is just a convenient way (or may more linux like) way of doing what was already possible, instead of wrap such functionality on a function that does not need to be changed ever again, that would implement the same functionality even if in a slight less performant way… its lol

@MyTDT-Mysoft Feel free to contribute to the project.

@K4sum1 Why do guard rails exist that waste metal and cost money? Because they deter from entering dangerous areas. Node.js makes no security guarantees on Windows 7. You can still climb over guard rails and you can still use Node.js on Windows 7 by simply setting NODE_SKIP_PLATFORM_CHECK as documented. But it also means you are on your own.

So your analogy compares possible death to running a program on a OS with millions of users? Good going there.

So your analogy compares possible death to running a program on a OS with millions of users?

@K4sum1 That’s clearly a straw man argument, and I’m tired of arguing against logical fallacies…

The dangerous part is not «running a program on a OS», as you misrepresent it. The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don’t see any danger in doing that, but we do. Maybe your applications don’t deal with sensitive data or security-critical processes, but many do.

An analogy is «a comparison of two otherwise unlike things based on resemblance of a particular aspect». In this case, the «two otherwise unlike things» are danger in real life and danger within computer systems, and the «particular aspect» is a mechanism that deters from said danger but that can be bypassed. So you are somewhat correct, it is an analogy, even though you misrepresent its meaning. The analogy does not at all imply that one danger is comparable to the other, but pretending that it does (as you just did) is a useful straw man, assuming one is willing to resort to logical fallacies.

Lastly, «millions of users» does not support your point at all. If millions of people walk along a dangerous area with no guard rail, the risk is certainly higher than if there were only a few people. Similarly, if millions of users run node on an unsupported platform with no security guarantees, the risk is higher than if there were only a few users.

ok, so that means you will do whats possible to have it working, but you wont care about security, which is totally fine, but dont shove unrequested security out of one throat, also isnt like it will have security problems because its on win7 unless its a bug with win7, which then its not even your job to protect against… but then again maybe we should put the fault on other projects that depend on node… that shouldnt be using it… since node wants to care about web server security, which is not aligned with the offline usage of such projects like emscripten, where all this «security» is irrelevant

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don’t see any danger in doing that, but we do. Maybe your applications don’t deal with sensitive data or security-critical processes, but many do.

Anyone with 7 is either going to stick with 12, or use the environment variable, sensitive data or not. I just use a portable version of 12 on my drive for when I need to use Node.js, and it works fine. You can’t stop me from using 12 on 7, unless that code gets removed, and I can use the latest version without modification. Yes I’m too lazy to set an environment variable, and I’m definitely not maining 10 any time soon, fight me.

Also anyone in a security critical situation that has 7 has either ESU updates, or uses 0patch, meaning the weak point in this case would be Node.js 12, not Windows. Also if security is the reason, why did Node.js drop the still officially supported Server 2012 R1?

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don’t see any danger in doing that, but we do. Maybe your applications don’t deal with sensitive data or security-critical processes, but many do.

Anyone with 7 is either going to stick with 12, or use the environment variable, sensitive data or not. I just use a portable version of 12 on my drive for when I need to use Node.js, and it works fine. You can’t stop me from using 12 on 7, unless that code gets removed, and I can use the latest version without modification. Yes I’m too lazy to set an environment variable, and I’m definitely not maining 10 any time soon, fight me.

Also anyone in a security critical situation that has 7 has either ESU updates, or uses 0patch, meaning the weak point in this case would be Node.js 12, not Windows. Also if security is the reason, why did Node.js drop the still officially supported Server 2012 R1?

Just wipe your hard drive and install Debian.

@tniessen

The dangerous part is running a program that makes no security guarantees on an unsupported OS that many users do not receive security patches for. It might be that you don’t see any danger in doing that, but we do. Maybe your applications don’t deal with sensitive data or security-critical processes, but many do.

OMG what a mess…

Firstly, in your «supported system» there are no less known holes than in the ancient seven. Even if not more considering that the new Windows has now become a target for intruders.

Secondly — if a person really cared about security, he would at least not write his applications in JS, think about it.

Good to know there is a trick to run Node 14+ on Windows 7 with NODE_SKIP_PLATFORM_CHECK=1.

For me, I choose to develop with Windows 7 but deploy onto Linux. As long as all required node_modules can be installed properly on both Win7 and my Linux distribution, I will still manually upgrade Node carefully.

Out of my curiosity, is there any real security issue encountered when running Node 14+ on Windows 7?

Secondly — if a person really cared about security, he would at least not write his applications in JS, think about it.

@Psychosynthesis I read this sentence at least a dozen times. I followed your advice and thought about it. And yet, I still can’t tell if you are joking, and I still have no idea what to say to this.

@stanleyxu2005 Yes, there is a simple trick to run newer Node.js versions on Windows 7. You can even set the environment variable globally, either system-wide or at least for a user, so you only have to do it once.

Out of my curiosity, is there any real security issue encountered when running Node 14+ on Windows 7?

I am not aware of any that are specific to Windows 7. Then again, we don’t test or audit on Windows 7, and I believe most security researchers have moved on to newer operating systems as well. We also have a bug bounty program but unsupported operating systems might be out of scope, so people might have less incentive to report security issues related to Windows 7.

As much as I appreciate hostile comments from people who complain about non-profit software that they don’t contribute to, I’d like to get this back on track. Is installation of Node.js 14 or newer still an issue on Windows 7 when the environment variable is set properly? If so, please provide more information or open a PR to address the issue.

Secondly — if a person really cared about security, he would at least not write his applications in JS, think about it.

@Psychosynthesis I read this sentence at least a dozen times. I followed your advice and thought about it. And yet, I still can’t tell if you are joking, and I still have no idea what to say to this.

Javascript isn’t known for its security. I would start complaining, but I know a lot of shit isn’t entirely the fault of Javascript itself, but other shit too.

As much as I appreciate hostile comments from people who complain about non-profit software that they don’t contribute to, I’d like to get this back on track. Is installation of Node.js 14 or newer still an issue on Windows 7 when the environment variable is set properly? If so, please provide more information or open a PR to address the issue.

I think once I tried setting it, but it still didn’t install. I think the installer should just give a prompt saying 7 isn’t fully supported and remove the code that looks for the variable in the installer and the program.

Also if 7 was dropped for security, why was Server 2012 R1, a still supported OS, dropped with it?

also i think when people say that theres an issue even for a not supported OS, but there isnt really a reason do to that, like not paying attention and using an optional new code path that would require a new OS, even if you dont normally test on it, i think for a big project like that, isnt really fair to dismiss people that showed that theres a problem that shouldnt exist, like i dont see a reason for Node to even require win7 instead of XP for example.

and has it was said using what MS support as a reason to support or not something is really a bad thing, and i’ve seen lately lot of people saying that as a justification, like many not having 32bit support even when it had 32bit support and the windows version they require also have 32bit support, so yeah, i think people should always put requirements to a minimum and optionally building on that even without priority or formal support, but never dismissing something that is simple to adjust, helping the requirements to be kept as minimum as it can be.

I doubt this thread is going to result in productive outcomes so I’m taking the liberty of putting it out to pasture. Please file a new issue if there are legitimate installation problems.

I had same problem with Win-7 with node-v6.10.3-x64.msi and node-v6.10.3-x86.msi installers.

Solution:

Download the Zipped version; When extracting, note the file that causes error.
Then, using Explorer, drill down to the target folder, created an empty file, then copy the content of archived file into the new, empty file.

I think the FQ path to destination is too long. Following is the error message I received.

!   C:Users......Downloadsnode-v6.10.3-win-x64.zip: Cannot create node-v6.10.3-win-x64node_modulesnpmnode_modulesnpm-registry-clientnode_modulesnpmlognode_modulesgaugenode_modulesstring-widthnode_modulesis-fullwidth-code-pointnode_modulesnumber-is-nanpackage.json

!   The system cannot find the path specified.

answered Jun 1, 2017 at 20:52