Bump default minimum node version for generated code?

[Alon Zakai]

Hi everyone,

We are considering bumping the default minimum node version for emscripten-generated code, from 10.19 to 15.0:

https://github.com/emscripten-core/emscripten/pull/19192/files

The main motivation is that 10.19 is quite old at this point so most people are likely using newer versions. And 15.0 supports wasm-bigint integration, which would allow us to use that by default (which is nice as it avoids workarounds for i64 values otherwise not being usable between wasm and JS - that helps code size, speed, and compile times).

Concretely, with this change, running

emcc test/hello_world.c

would emit a.out.js and a.out.wasm that depend on node 15.0 to run. If you run a.out.js in an older node you'll get an error in a build with assertions enabled.

Note that this only affects the node version - if you never run your code in node (maybe you always run in a browser) then this won't affect you. This is also unrelated to the node version emcc itself uses internally for the JS compiler and optimizer etc. Note also that this would only affect the *default* version, but it will still be possible to set a different node minimum version, using

emcc -sMIN_NODE_VERSION=101900

That sets it to 10.19.0 (the old default). That is, this just changes the default, but support for older node versions is still possible if you set a flag.

Overall this seems like a useful change (as mentioned, this gets us closer to enabling wasm-bigint by default), and with low risk. In particular, the node website's downloads are all of newer versions - even the LTS download is higher than 15.0 (by a significant amount - 18.16). However, this might mean that, say, someone using the default node in their Linux distro might run into an issue, as e.g. latest Ubuntu LTS seems to have an older version (12.0), so I wanted to check on the mailing list what people thought. It is nice to have emcc output "just work" in common node versions, but I'm not sure which are the most commonly-used...

- Alon

[Shlomi Fish]

hi Alon, and all

On Mon, 17 Apr 2023 16:56:01 -0700
Alon Zakai <alon...@gmail.com> wrote:

> Hi everyone,
>
> We are considering bumping the default minimum node version for
> emscripten-generated code, from 10.19 to 15.0:
>
> https://github.com/emscripten-core/emscripten/pull/19192/files
>
> The main motivation is that 10.19 is quite old at this point so most people
> are likely using newer versions. And 15.0 supports wasm-bigint integration,
> which would allow us to use that by default (which is nice as it avoids
> workarounds for i64 values otherwise not being usable between wasm and JS -
> that helps code size, speed, and compile times).
>

I approve of the version bump.

> sure which are the most commonly-used...
>
> - Alon
>

--

Shlomi Fish https://www.shlomifish.org/
Humanity - Parody of Modern Life - https://shlom.in/humanity

Larry Wall applies a patch manually quicker than GNU patch.
— https://www.shlomifish.org/humour/bits/facts/Larry-Wall/

Please reply to list if it's a mailing list post - https://shlom.in/reply .

[Ulhas Pawar]

Hello!

Does it make sense to bump version to even numbered node release:

https://nodesource.com/blog/understanding-how-node-js-release-lines-work/

Odd numbered releases are killed soon and LTS is only for even number releases.

Thanks,

Ulhas

--
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 on the web visit https://groups.google.com/d/msgid/emscripten-discuss/20230418045243.36cebef6%40shlomifish.org.

[Jukka Jylänki]

This sounds good to me. Ulhas has a good point about the version numbers, a LTS might be more desirable.

Another thing to note is that Node 10.19 supported Windows 7, and starting from Node 14.x, Windows 8.1 or higher is required. So this change does mean dropping Windows 7 support. I think it is about time that happens though.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAHSofyMuOubf5kCTa_5vVPF_tGmmKKS2LjefEJBoGG78q7U%2B-w%40mail.gmail.com.

[Sam Clegg]

Note that there are three distinct node versions at play in the emscripten world.   One has already been bumped. and one we plan to bump, and one we don't have plans to change.

1. Min version required to run output code (this is only the default can can be lowered via setting):  

     10.19.0 -> 15.0.0 (PLANNED UPDATE)

2. Version of node we ship in emsdk: 

     14.15.5 -> 15.14.0  (ALREADY UPDATED)  (https://github.com/emscripten-core/emsdk/pull/829)

3. Min version required to run emcc itself: 

     10.19.0  (NO CHANGE PLANNED) (https://github.com/emscripten-core/emscripten/blob/1e7b78fe45cee0b96b64938f9742368923cd0713/tools/shared.py#L51) 

Note that for (3) we do a minimal amount of testing of emcc with this pinned (very old) version of node just to ensure folks can run emcc on very old systems.   The only reason we would ever need to bump this number would be if our internal usage of JS in the JS compiler required some new node or JS feature.

Since emsdk (2) has already been updated, I'm not sure there is any reason to update again from 15.14.0 to 16.0.0.  I'm not sure what benefit that would have. 

For (1) I also don't see what there is to be gained from artificially bumping up from 15 to 16.   That would just seem to limit artifiically limit that places where emscripten output can run since the output doesn't actually depend on any features that are not available in 15.

On Tue, Apr 18, 2023 at 4:29 AM Jukka Jylänki <juj...@gmail.com> wrote:

This sounds good to me. Ulhas has a good point about the version numbers, a LTS might be more desirable.

Another thing to note is that Node 10.19 supported Windows 7, and starting from Node 14.x, Windows 8.1 or higher is required. So this change does mean dropping Windows 7 support. I think it is about time that happens though.

That is interesting.  Note that emsdk updated past 10.19 a long time ago so in terms of running emsdk itself I guess that ship has long sailed.  The proposed change here would mean if you wanted to run the *output* of emscripten on a windows 7 machine you would need to specify `-sMIN_NODE_VERSION=101900`.. but it should still be runnable once you did that. 

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-0fdzqYKKKdm-OzVdG5Q3rpcUFcvWXLPEq%3DwCXdRAnAdg%40mail.gmail.com.

[Alon Zakai]

On Tue, Apr 18, 2023 at 9:14 AM 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

Note that there are three distinct node versions at play in the emscripten world.   One has already been bumped. and one we plan to bump, and one we don't have plans to change.

1. Min version required to run output code (this is only the default can can be lowered via setting):  

     10.19.0 -> 15.0.0 (PLANNED UPDATE)

2. Version of node we ship in emsdk: 

     14.15.5 -> 15.14.0  (ALREADY UPDATED)  (https://github.com/emscripten-core/emsdk/pull/829)

3. Min version required to run emcc itself: 

     10.19.0  (NO CHANGE PLANNED) (https://github.com/emscripten-core/emscripten/blob/1e7b78fe45cee0b96b64938f9742368923cd0713/tools/shared.py#L51) 

Note that for (3) we do a minimal amount of testing of emcc with this pinned (very old) version of node just to ensure folks can run emcc on very old systems.   The only reason we would ever need to bump this number would be if our internal usage of JS in the JS compiler required some new node or JS feature.

Since emsdk (2) has already been updated, I'm not sure there is any reason to update again from 15.14.0 to 16.0.0.  I'm not sure what benefit that would have. 

For (1) I also don't see what there is to be gained from artificially bumping up from 15 to 16.   That would just seem to limit artifiically limit that places where emscripten output can run since the output doesn't actually depend on any features that are not available in 15.

Interesting points. On the one hand I agree with Ulhas and Jukka that it is odd to set a default version number that isn't an LTS version, since who would be using an older version that is not LTS? (non-LTS versions are no longer supported after 6 months, I believe) But on the other hand moving from 15 to 16 would only support less things as Sam says (running in 16 will work if we set 15, but not in reverse).

Is there any data on version usage? I can't seem to find any. But if the data showed that practically no one uses anything but LTS versions then 16 might make more sense. Or, if older non-LTS versions are used sometimes then maybe not.

- Alon

 

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29QxzpKwqvzw9i3gi4Jq-_PKzCPo9q7BTXL%3D4kHZL7L8g%40mail.gmail.com.