Emscripten 6.0.2 still has Node.js 22.16.0

[John Dallman]

Is this deliberate? My software security people are pointing out that it's the same version as was in Emscripten 4.0.21, so it is pretty old. The latest 22.x is 22.23.1, from 16-JUN-2026. 

I used Node for the first time when I started on Emscripten, so I'm a bit cautious about trying to install my own. I'm working on Linux.

Thanks, 

John Dallman

 

[Sam Clegg]

Hi John,

What you are referring to with 22.16.0 is the version of node that is bundled with emsdk.   We don't tend to update this very often, for various reasons.   Note that emscripten uses node only for its internal JS compiler.  This means its only used to process your code, not, for example, untrusted code from the internet.

If you have concerns about it fairly easy to just avoid using it.   You can configure emscripten to use any version of node you like (by setting `NODE=` in your config file or `EM_NODE=` as an environment variable).

For example, if you would prefer to use your linux distributions version of node with emscripten you should be able to simply `export EM_NODE=/usr/bin/node`.     You could instead edit `/path/to/emsdk/.emscripten` config file (but you may need to re-edit this each time you run emsdk installs a new version).

cheers,

sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgnEC%2B4oUWNZ2vKEGGPvsfYqbCr2KfBqLHwzwcGYNncSmQ%40mail.gmail.com.

[John Dallman]

> Note that emscripten uses node only for its internal JS compiler.  This means it's only used 

> to process your code, not, for example, untrusted code from the internet.

Oh. I've been using it for testing stuff I build, simply because it was already on PATH. 

Would a sounder method be to leave $EMSDK_NODE alone, so that Emscripten can use the version it was tested with for compiling and put another version of Node on PATH ahead of the Emscripten entries? If so, do I need any other environment variables set for the other version of Node? 

Yes, I'm being extremely cautious. I'm under a lot of time pressure, and my knowledge of web application programming is very limited. I keep finding I'm making wrong assumptions, and/or running into things that seem weird to me. Many things that seem utterly obvious to you are strange to me. 

Thanks, 

John

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-sxHr8m3Jbd1FAj%2B7DJ2x-HkVOLNtwWGiO3O756pZRxw%40mail.gmail.com.

[Sam Clegg]

On Tue, Jul 14, 2026 at 3:24 AM John Dallman <jgdats...@gmail.com> wrote:

> Note that emscripten uses node only for its internal JS compiler.  This means it's only used 

> to process your code, not, for example, untrusted code from the internet.

Oh. I've been using it for testing stuff I build, simply because it was already on PATH. 

Indeed if you put some other version of node in your path we have code in emsdk that will ensure that the emsdk version is *not* installed in your PATH:   https://github.com/emscripten-core/emsdk/blob/main/emsdk_manifest.json#L190.   This line means that if `node` is found in your PATH we will not add the path or the emsdk node (Although emscripten itself will still use it).

Would a sounder method be to leave $EMSDK_NODE alone, so that Emscripten can use the version it was tested with for compiling and put another version of Node on PATH ahead of the Emscripten entries? If so, do I need any other environment variables set for the other version of Node? 

No, you should not need to do anything special to run the emscripten-generated code on any version of node you like.. as long as it is recent enough (The current default min version for the generated code is 18.3).
 

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgkUwJS8avEO8J4OYZY4Bbsw2%2BMK1xiFDc%3DfEhU7xcyBUw%40mail.gmail.com.

[John Dallman]

We don't keep Node on PATH at present, because the only use we make of it is with Emscripten-related work. We use the same machines and accounts to work on products for Linux with a GCC Toolset, Android with the NDK, and WebAssembly with Emscripten, and we naturally prefer to keep those environments separate. 

It sounds as if the correct strategy is: 

• Download and install a recent version of Node.js. 
• When we initialise our development/test environment, put that Node onto the front of PATH before running emsdk_env.sh.  

Is that workable? 

 

Thanks,

John Dallman

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-P%3D6J1mPEy7vEpA%2BNPYrax%3D22H%2BCxHZAY_x9pTONHdTQ%40mail.gmail.com.

[Sam Clegg]

On Wed, Jul 15, 2026 at 4:56 AM John Dallman <jgdats...@gmail.com> wrote:

We don't keep Node on PATH at present, because the only use we make of it is with Emscripten-related work. We use the same machines and accounts to work on products for Linux with a GCC Toolset, Android with the NDK, and WebAssembly with Emscripten, and we naturally prefer to keep those environments separate. 

It sounds as if the correct strategy is: 

• Download and install a recent version of Node.js. 
• When we initialise our development/test environment, put that Node onto the front of PATH before running emsdk_env.sh.  

Is that workable? 

I think its even simpler than that.  If you don't want to keep node in your PATH, then just download and use the node version you want.

e.g. `/path/to/my/node <app>.js`

With that method that PATH, and what emsdk might or might not do it, is not relevant anyway.

 

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqg%3D7nwvze7rfozrbB4HS5zSoFJ6upfjNdUuHsQL7XsYxPw%40mail.gmail.com.

[John Dallman]

I wasn't clear. We would like to have Node on PATH inside our development environment when that is using Emscripten, but not when outside the development environment, or when using the development environment for platforms that don't involve WebAssembly. 

The development environment is very simple: a bash shell with additional environment variables set and extra PATH entries. If I've understood you correctly, adding a Node for running tests on to the front of PATH before source'ing  emsk_env.sh should work. I think that would mean that running node via PATH will get us our testing Node version, while Emscripten will use its bundled Node version for internal stuff.

Thanks,

John Dallman  

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-AVUVQC%2Bm1uAZW5p2%3D8b0gxWXn%2BGORtic9-VMuq2L9eQ%40mail.gmail.com.

[Sam Clegg]

On Fri, Jul 17, 2026 at 4:31 AM John Dallman <jgdats...@gmail.com> wrote:

I wasn't clear. We would like to have Node on PATH inside our development environment when that is using Emscripten, but not when outside the development environment, or when using the development environment for platforms that don't involve WebAssembly. 

The development environment is very simple: a bash shell with additional environment variables set and extra PATH entries. If I've understood you correctly, adding a Node for running tests on to the front of PATH before source'ing  emsk_env.sh should work. I think that would mean that running node via PATH will get us our testing Node version, while Emscripten will use its bundled Node version for internal stuff.

That is correct.   If you use emsdk then emscripten will always use the node configured via the config file, and ignore any node versions in your PATH.

If you did want emscripten to use node from your PATH you would want to delete the `NODE = ` entry from your config file.

 

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqg%3D23_qMZBk%3DkLkv-w%2BWN4MGTpPxom-HXCHj-afq69K%3DJg%40mail.gmail.com.

[John Dallman]

Thanks, that's clear now. 

John

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29uGJ967oDd-6qMDEyRFNBGiHSr1jU5ocR3HqytTFvKtw%40mail.gmail.com.