Node.js Weekly:
“ Node.js 26.0 (Current) Released — It’s here! Complete with the Temporal API enabled by default…”
Node.js Weekly:
“ Node.js 26.0 (Current) Released — It’s here! Complete with the Temporal API enabled by default…”
Super hyped about this! Node 24 will be in Meteor 3.5, I will soon submit a PR with Node 26 for Meteor 3.6.
Me too! Up until now dates in node have been very tough to use and debug. This is going to be a big step forward.
Here we go:
we will need to launch a new beta containing a few fixes from the last beta, so I’ll try to include node 26 ![]()
[EDIT]
I’m reconsidering to include the node 26 in the release 3.5 since it isn’t LTS, I would like to discuss better the non-LTS usage at meteor before move foward.
My opnion about it is that non-LTS versions have a very short active lifecycle (typically 6 months) and serve as a proving ground for the Node.js team, we would be held hostage to frequent breaking changes and regressions(maybe maybe). A second and most important argument is about the enterprise users, they sustains large applications in production that operates under strict security policies (IT compliance) that prohibit the deployment of non-LTS runtimes. If the source requires or optimizes for a Current version, it creates distrust. Companies will simply freeze framework updates, fragmenting the community and delaying the adoption of new major releases.
I would to patch the node 24 instead Node 26
Node 26 will be LTS in October.