[feature] Upgrade to Node.js 20(LTS)

[DreamOfIce]

As written in https://github.com/nodejs/release#release-schedule, support for node.js 16 was end in September 2023.
Therefore, it is recommended to upgrade to node.js 20.
Also, many of the features in node.js 20 are enabled by default, such as --experimental-wasm-threads and --experimental-wasm-bulk-memory.

[sbc100]

We are looking into this right now. See #829 for more discussion.

One current blocker is that out CI builders currently run on ubuntu/bionic and node 18 decided to drop support for the version of glibc that is included with ubuntu/bionic. I think we will likely have to follow suite and drop support for bionic and update our builders.

[sbc100]

Moved to emsdk since its the emsdk version of node we are talking about upgrading (emscripten itself already supports newer versions).

[DreamOfIce]

We are looking into this right now. See #829 for more discussion.

One current blocker is that out CI builders currently run on ubuntu/bionic and node 18 decided to drop support for the version of glibc that is included with ubuntu/bionic. I think we will likely have to follow suite and drop support for bionic and update our builders.

Are there any impediments to updating ci's version of Ubuntu? After all, the five-year free support period for Ubuntu 18 is almost up

[sbc100]

Yes, there were impediments. We don't have direct control over the VM. But I think we have now overcome those.

BTW, according to https://wiki.ubuntu.com/Releases ubunut/bionic 18.04 LTS is supported until April 2028.

The issue of what version of node we use internally in emsdk should really be an implementation detail though. I think the real issue is that we are putting our internal version of node in the emsdk user's path, and we should focus on fixing that. Even if/when we update to node v18 that will also be wrong version for many users who have already installed their own.

[DreamOfIce]

I agree with this, forcing the specified version of node into path is a very bad idea. We should at least provide an option to use the system node.

Considering that the lifecycle of node.js14 is coming to an end, updating the bundled node version is the big trend.

BTW, the free LTS period for Ubuntu 18 will end in April and paid commercial support for the next five years

[sbc100]

Considering that the lifecycle of node.js14 is coming to an end, updating the bundled node version is unavoidable, even if only for security reasons

I think unavoidable might be too strong a word there. Perhaps inadvisable.

[sbc100]

Considering that the lifecycle of node.js14 is coming to an end, updating the bundled node version is unavoidable, even if only for security reasons

Emscripten's use of node is as part of the compiler toolchain and as such it does not process untrusted code. There is no protection at all against hostile user input in emscripten, regardless of node version. For example --library-js=foo.js executes foo.js with full user permissions at build time.

[DreamOfIce]

Considering that the lifecycle of node.js14 is coming to an end, updating the bundled node version is unavoidable, even if only for security reasons

I think unavoidable might be too strong a word there. Perhaps inadvisable.

You're right, this is indeed a bit too absolute

[DreamOfIce]

Yes, there were impediments. We don't have direct control over the VM. But I think we have now overcome those.

BTW, according to https://wiki.ubuntu.com/Releases ubunut/bionic 18.04 LTS is supported until April 2028.

The issue of what version of node we use internally in emsdk should really be an implementation detail though. I think the real issue is that we are putting our internal version of node in the emsdk user's path, and we should focus on fixing that. Even if/when we update to node v18 that will also be wrong version for many users who have already installed their own.

@sbc100 After some changes, I successfully upgrade Ubuntu to 22.04LTS in .circleci/config.yml.The only change is the removal of running flake with python2 and only keeping python3, as installing both pip versions at the same time would report an error. Of course, it's easy to add python2 back if necessary.
Commit and CI status: DreamOfIce@d9f78ac