Support later versions of Node (or make version configurable)

[blittle]

Is your feature request related to a problem? Please describe:
At Shopify we heavily use https://hydrogen.new for sharing and promoting the Hydrogen Framework. We recently made changes that require Node v16.5.0 or greater. If there's no way to configure stackblitz to use Node 16, we'll probably revert those changes until this issue is resolved.

Describe the solution you'd like:
We'd like a way to configure which version of NodeJS the stackblitz container runs with.

Describe alternatives you've considered:
Our alternative is to 1) not use stackblitz or 2) revert our Node 16 specific features, though this will have to be tempoarary because the features are required for our 1.0 launch.

Additional context:
Related issue: stackblitz/core#1622

[EricSimons]

Hey @Blittle- thanks for reporting this. Node 16 support is on our roadmap for Q1 and WIP on our side. Supporting multiple Node versions is a big change in webcontainer so this will likely take a few months to land, but after that it will be much easier for us to add support for subsequent versions of Node (and other langs/runtimes).

I'm curious what specific features of Node 16 that Hydrogen is relying on that isn't present in 14? Depending on what those are there might be something we can do from our side as a temp solution, or perhaps some sort of polyfill approach in Hydrogen core that would allow Node 14 users to also run Hydrogen v1?

[blittle]

Hi @EricSimons thank you for the response! It's great to hear that Node 16 is WIP. The specific features we rely upon are the ReadableStream API. Though I'm currently exploring alternatives.

[trentprynn]

Just chiming in to add that I'm excited for this feature and add a reason it will be super useful to me!

Currently I primarily use stackblitz as a way to share bug reproductions (it's awesome for this, thank you!) and I'm having a problem I'm relatively sure is related node@16 that I cannot reproduce / share this way because stackblitz only currently only supports node@14

[FossPrime]

For me it's webcrypto... completely missing in Node 14

import Koa from 'koa'
import logger from 'koa-logger'
import Router from '@koa/router'
import { webcrypto } from 'crypto'

const crypto = webcrypto as unknown as Crypto

const random = crypto.getRandomValues(new Uint8Array(24))

import { webcrypto } from 'crypto';
         ^^^^^^^^^
SyntaxError: The requested module 'crypto' does not provide an export named 'webcrypto'

https://stackblitz.com/edit/koa-starter-wychx9?file=src%2Findex.ts

[jycouet]

I just found out that we are on node v14.19.0, any idea when we will be able to tune this with a parameter?
Thank you

[FossPrime]

I just found out that we are on node v14.19.0, any idea when we will be able to tune this with a parameter? Thank you

I'm against taking the burden of supporting multiple versions of node. If someone needs to archive everything, containers are better for that. It would be nice to have the option of using node 17, but what we'll always desperately need is the current LTS, which right now is 16.

Very few projects will break going from 14 to 16. When they do, the fix is usually trivial. Right now there is no production pipeline that will break if we hard switch everyone to Node 16. So lets switch everyone to LTS and forget about 14, it's the easiest, cheapest and best route long term and short term.

[codepunkt]

The live servers don't have the latest LTS.

Stackblitz and other platforms are amazing for providing error reproductions - but whenever these error reproductions are connected to specific Node.js versions, you're out of look. It would be a big boost to our usage of Stackblitz if we could choose the Node version we want, including minors and pre-releases.

[vlucas]

Re-visiting this issue because Node 18 has landed and includes support for some major web primitives that are now built-in to Node itself as globals. Things like fetch, FormData, Request, etc. that we use a lot in Hydrogen.

Node 18 also includes Web Streams (ReadableStream, WriteableStream`, etc.) now built-in the global Node namespace that Hydrogen makes heavy use of for streaming server responses with React 18.

Upgrading to Node 18 and requiring it as the minimum version to use Hydrogen means we would no longer have to use feature detection or polyfill anything. This would improve performance and reduce overall bundle and install size for all Hydrogen apps (as well as many other Node apps too that no longer have to use things like node-fetch!).

Do you have any ETA on when we can specify a specific Node version in our own container, or when you can upgrade to Node 18 (the next LTS version)?

[d3lm]

Hey there 👋 We are planning to upgrade to Node 18 in the next quarter or two before 16 goes out of maintenance. We keep you posted here.

[thescientist13]

@d3lm
Great to hear! A lot of great Web APIs landed in Node 18 like native fetch, URL, Request and Response so it would be great to see support for those in Web Containers. 💯
https://stackblitz.com/github/projectevergreen/greenwood-getting-started

[d3lm]

Yea, once upgraded to 18 those should work 👍

[bluwy]

Leaving a note that Astro 3.0 (releasing before node16 EOL) will only support node18 and above. So it might temporarily not work in stackblitz as we use some node18 APIs, like File, Headers, Request, fetch.

[nickwinger]

With the Qwik Framework and server side functions to work, we would also need node 18

[brophdawg11]

Remix v2 also upgraded to a minimum of Node 18, so we'd love to see this become configurable (or raised to active LTS)