ts-node EOL schedule for TS and Node versions

[jhmaster2000]

This is a discussion in a very similar spirit as DefinitelyTyped/DefinitelyTyped#40050

The issue above from DT discusses terminating DT's support for TS 2.7 for several reasons such as the maintenance cost of supporting so many TS versions. They ultimately decided to go forward with it and all went well, and now they have a successful standardized EOL schedule for TS versions as seen here: https://github.com/DefinitelyTyped/DefinitelyTyped#support-window

That happened nearly 2 years ago. Now we look at ts-node and we see it still supporting TS 2.7 (as can be seen by the Github Actions tests with 2.7 as the minimum tested version and the package.json). On top of that, ts-node is also in some way dependent on Node.js v10 still, as seen here, which has reached EOL nearly over a year ago, with Node.js v12 to reach EOL in just a month.

So the question here is, why? Is there an actual technical need for these unwieldly large support ranges, Node v10 to nightly, TS 2.7 all the way to 4.7 and nightly? I have tried to look around for past information on the topic, all I could find was #1316, a closed issue with no real visible resolution, as there is no comment actually answering the question of the reason for it, nor any linked PRs or anything, which leads me to open this discussion in hopes it can be clarified here, and if there is no technical needs, I would find it productive to extend this discussion to establishing a standard EOL schedule for ts-node's TS and Node versions (and possibly versions of ts-node itself by extension?) so that ts-node doesn't fall into the kind of development hell it is in right now by falling 2 years behind of EOLs.

As an initial proposal, based on the statistics provided by this comment on DT's issue, 2 years time range for TS versions support by ts-node also seems more than reasonable, with the benefit of being on sync with DT's schedule, so anyone using DT and ts-node would have to upgrade both anyway even without ts-node having it's own schedule. This would mean immediately dropping support for 2.7 until 3.8 on the next major release (v11), turning the minimum version into 3.9, although considering the time it may take to prepare for this change, it's probably best to just aim straight for 4.0.

A similar case with Node versions, nothing unreasonable with simply following Node's EOL schedule, why support Node versions that Node themselves don't? This means dropping v10 and v12 (in a month, but again, considering the time it may take to prepare these big changes).

Summing it all up, ts-node v11 would have an ideal support range of:

• TS: 4.0 to 4.7 & nightly
• Node: v14, v16, v17, v18 & nightly

Both far more sane and maintainable support ranges.

[cspotcode]

See also: #1505

[jhmaster2000]

Ah nice, I couldn't find that from searching issues. I feel like that issue should be pinned and linked to from #1316.

What about dropping of Node versions (v10, soon v12) and establishing an EOL schedule for those too?

[cspotcode]

Some more info:

• We are not dependent on node v10. We do not run our tests against node v10
• We are not in "development hell"
• We support the latest node and typescript nightly versions, so we're not falling behind
• Github limits the total number of pinned issues
• When we drop support for node versions, it is documented as a breaking change: https://github.com/TypeStrong/ts-node/releases/v10.0.0
• We will accept a documentation update to state our currently supported node versions. But it should not claim that we will drop support for node 12 immediately when it's EOLed. Support will be dropped in ts-node v11 if v11 happens after node 12 has EOLed (which is likely)

As long as we can continue delivering useful new features and bugfixes on v10, I'm going to keep going with v10. It's good for users. Eventually v11 will happen, and we'll do all those tweaks listed in #1505.

I think that covers everything.

[jhmaster2000]

Appreciate the info! Some followup questions/clarifications:

• What is the node10 tsconfig for then? Old leftover? 🤔
• Fair I definitely exaggerated there with "development hell" but specifically looking at tests they are pretty bad right now, taking between - 15 to 20 minutes to run them all on Github Actions and quite a few hacks and workarounds to fit TS 2.7's needs around the codebase, especially tests. All this will be easily solved by v11 though. 🎉
• By falling behind I meant in dropping obsolete versions, not in supporting latest ones :P
• Oh well didn't know that, welp, I'll comment on the issue linking to this discussion and the v11 issue then to at least create a link between those resources.
• Changelogs work nicely for those looking to update and know what they need to do, but someone not updating ts-node is more unlikely to look for info such as supported Node & TS versions on there, especially since it only gives them the minimum but not the maximum most of the time. It would be better documented in the README like DefinitelyTyped has.
• Might have been poor wording on my part, for sure, we shouldn't drop versions mid-major releases, wasn't suggesting that. An EOL table documentation would use ts-node versions as "cycles" rather than dates/times, the ones I mention on the discussion are simply "ideal" time intervals to make the major releases to be in reasonably close alignment with EOLs of Node and DT while still following semver majors.