✨ Consider Pinning Node to LTS release

[levlaz]

What are you trying to do?

A user reported that they were surprised to see us using a non-LTS version of Node in our Typescript SDK.

We should consider pinning our TypeScript SDK to the LTS version of node as we approach "dagger 1.0"

Why is this important to you?

Since we expect people to adopt this SDK in their production pipelines, I think we will have a lot less issues long term if we stick to a stable version of node. Node's own documentation recommends using only LTS releases for production applications since they will come with 30 months of support instead of just 6 (for odd numbered releases)

Major Node.js versions enter Current release status for six months, which gives library authors time to add support for them. After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to Active LTS status and are ready for general use. LTS release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use Active LTS or Maintenance LTS releases.

How are you currently working around this?

N/A

[TomChv]

Thanks for reporting, I can take care of the changes and see if it break anything this week.

[TomChv]

As explained in #7481, instead of pinning Node to LTS release, we'll support dynamic version so the user can configure which version he wants to use by setting the field engine.node in its package.json.

By default, we'll use the LTS version, probably 20.14 until v22 become the active LTS release.

Here's a copy of the discussion in #7481

Node upgrades / downgrades are always tricky since its not just the user code that you have to be worried about. Internally we use 20.11, and one of our devs was setting up a new machine and he had 20.13 installed. Things broke.

I like the ability to configure which version of node is used, while having a minimum supported version. Something like this will probably be needed for the bun runtime since that is adding new features on a quicker cadence

Alright, I'm closing this PR for now, as you said, it's better to allow node configuration which is possible by checking the engine.node field of the package.json.

I'll take care of that later, I'll put a comment in the issue as a reminder