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)

[SamVerschueren]

We are planning to release an upgrade to Node.js 18 in the coming 1 to 2 weeks. We will definitely keep everyone posted.

The plan is to drop support for Node.js 16, as it is end of life. Starting from Node.js 20, we want users to be able to configure/switch a specific LTS version. More info will follow once we are there.

We also want to be more transparant to the future on the release cadance of Node.js upgrades. We want to do better in communicating this so it's clear for everyone and there are no surprises.

[austinm911]

T3-Turbo requires Node.20.10 so unable to get it working on Stackblitz

[NullVoxPopuli]

We are planning to release an upgrade to Node.js 18 in the coming 1 to 2 weeks

Didn't look like this happened?

I opened an issue here: stackblitz/core#2926

webpack is totally broken (if using the thread-loader, due to the libUV issue nodejs/node#49911)

[SamVerschueren]

Didn't look like this happened?

We did do the upgrade from 16 to 18. This answer was not about upgrading to a different 18 minor.

webpack is totally broken (if using the thread-loader, due to the libUV issue nodejs/node#49911)

I already thought this issue looked familiar :). Apparently you ran into (and reported) it a couple months ago #1256. I also answered why thread-loader is broken in WebContainer.

[Sayvai]

The plan is to drop support for Node.js 16, as it is end of life. Starting from Node.js 20, we want users to be able to configure/switch a specific LTS version. More info will follow once we are there.

Loving the fact that there's a plan to allow devs to configure and switch between LTS versions.

Does that also make it easier for devs to get up to speed faster with new LTS releases on release days?

Also, do we have an idea of when Node.js 20 (LTS) will be supported? 🤔

[SamVerschueren]

Does that also make it easier for devs to get up to speed faster with new LTS releases on release days?

The plan (on paper) is to be able to support new LTS releases as soon as possible. Release day is probably too fast, but let's say within 4-6 weeks.

Also, do we have an idea of when Node.js 20 (LTS) will be supported?

We're aiming for Q2. We have already done some of the work but had to shift priorities. We will pick it up again very soon.

[newstart0514]

I really need it because in recent projects, some NPM packages require an environment with a minimum of NodeJS 20

Does that also make it easier for devs to get up to speed faster with new LTS releases on release days?

The plan (on paper) is to be able to support new LTS releases as soon as possible. Release day is probably too fast, but let's say within 4-6 weeks.

Also, do we have an idea of when Node.js 20 (LTS) will be supported?

We're aiming for Q2. We have already done some of the work but had to shift priorities. We will pick it up again very soon.

[GeeekyBoy]

We are planning to release an upgrade to Node.js 18 in the coming 1 to 2 weeks

Didn't look like this happened?

I opened an issue here: stackblitz/core#2926

webpack is totally broken (if using the thread-loader, due to the libUV issue nodejs/node#49911)

Good news 🎉
StackBlitz now uses Node.js v18.20.3 instead of Node.js v18.18.0.

[SamVerschueren]

Due to priorities, Node.js 20 is planned to be worked on starting end of July.

[ruckc]

@SamVerschueren ... and when Node 22 hits LTS in October?

[SamVerschueren]

The plan is to (almost) immediately start working on Node.js 22 after Node.js 20 has landed.

[eslachance]

Hey guys just reminding you that you're still on Node 18, and still haven't found a way to let us determine the version of node we want. This is honestly a little disappointing.

[didier]

Yep, stackblitz is on node 18.

[dirkluijk]

Radical idea: what if you can switch runtimes on StackBlitz? E.g. switch from Node to Deno, and also accept JSR as custom NPM registry. I think that would really boost collaboration in open-source JavaScript based projects.

Let me know if you need any contribution, I’d love to spend some time on this as a public feature.

[BananaAcid]

2 Weaks ago, a few of my projects started breaking ... more started following. Due to dependency updates and node being to old. npm ERR! t._handle.getAsyncId is not a function ... very unfortunate.

[jkoefer]

Any updates on this from the Stackblitz team?