Update bundled node.js to a more recent version

[dcodeIO]

I am using emscripten in conjunction with a node.js application. When I run emsdk or emcmdprompt, I find myself in a situation where I have to use two different terminals to not accidentally run my application with node 4.1.1 where APIs like Buffer.from are not working as expected.

Is there a reason for bundling 4.1.1 specifically or would a PR (if it's possible at all to solve it this way) to depend on something more recent, ideally 8.x with proper WebAssembly support now that it's out, be unproblematic?

[kripken]

cc @juj

[juj]

There is no specific reason for that version, it was the latest version at the time of when it was added. I can look into updating emsdk to latest.

As a workaround, you can try something hacky like replace the node executable in the 4.1.1 path with a newer version. That should work just fine. (let me know if it doesn't!)

[thomas-jeepe]

I'm gonna bump this as I have to go through many workarounds, for example I conditionally have the following in my .bash_profile:

cd ~/emsdk-portable
./emsdk activate latest
source ./emsdk_env.sh

I have to disable that when doing any js development, because I need node 8 as certain tools need more recent node versions.

In addition, I have a project where in CI/CD I want to compile emscripten, then compile something using node (which requires a later version), which make it a huge pain in the ass.

For now I will do some hacky workaround, but it seems to me that using a newer version of node would be a better solution for just about everyone. And perhaps even improve performance where node is needed.

Also, when using yarn:

warning You are using Node "4.1.1" which is not supported and may encounter bugs or unexpected behavior. Yarn supports the following semver range: "^4.8.0 || ^5.7.0 || ^6.2.2 || ^8.0.0"

[thomas-jeepe]

Stupid question: why do you even bundle node?

If node stays backwards compatible, many could use whatever version they want and if it is simply in the path, it is far simpler.

It also means less install time, etc.

Most everyone has node that is working with emscripten anyways.

You simply assert that node -v is above whatever the current version is and that node is in the PATH.

I suppose this could also be extended to clang, but I am not as familiar with the c/c++ tooling areas.

[thomas-jeepe]

@juj updates?

[aduh95]

@juj any news on this? If you need any help, please ask, I'd be happy to help if I can!

@thomas-jeepe I'd recommend you to set an alias instead, something like alias emcc_env_activate='source ~/Documents/emsdk/emsdk_env.sh --build=Release', so it will only affect your current bash environment.