Rocket.Chat
Replies: 7 comments
-
|
I think this post need an update since current Node LTS is 20 and I see the last update about it is from June 27. |
Beta Was this translation helpful? Give feedback.
-
|
The Link about the extended support window for NodeJS 14 for a year is only available for me via Archive.org When will this be fixed? |
Beta Was this translation helpful? Give feedback.
-
|
Are there any updates on this? |
Beta Was this translation helpful? Give feedback.
-
|
The special forked version of Node version 14 was only going to be supported by Meteor until April 2024. This would seem to imply that all Rocket Chat versions are again running Node without security support. |
Beta Was this translation helpful? Give feedback.
-
|
Also see Gabriels comment here. If you have further questions then ask here. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
Quick update here. Rocket.Chat version 7.0 is under release candidate and will bring the long-awaited update of NodeJS to version 20. Changelog -> https://github.com/RocketChat/Rocket.Chat/releases/tag/7.0.0-rc.0 Once we have the final release we will announce it here as well. |
Beta Was this translation helpful? Give feedback.
-
|
Team, FYI - 7.0 release is out -> https://github.com/RocketChat/Rocket.Chat/releases/tag/7.0.0 |
Beta Was this translation helpful? Give feedback.
-
Why do we still use NodeJS 14, not the latest LTS (18)?
Rocket.Chat is a project based on Meteor framework, which was popular when released due to being built on top of the fibers library, which changes the JavaScript behavior to transform async code in sync code, preventing the popular callback hell issue (remember that async/await didn't exist at the time). Fibers is a library that required native code and started to have compatibility issues with the NodeJS core code up to being deprecated and officially not working with NodeJS 16 and later.
To be able to go away from Fibers and replace it with a modern approach using async/await, Meteor would need to perform breaking changes to their API and require any software developed based on it to be completely rewritten. This led to the framework delaying the changes until the situation was critical.
What are we doing to make the NodeJS upgrade?
We migrated our code to async/await long ago, mostly replacing parts of the Meteor with a native approach. For example, we replaced most of our models using Meteor's collection by direct MongoDB collections without fibers. But still, most of our code was based on Fibers or depending on Meteor's functionalities.
So on March 9, 2023, we started an Epic to put all the effort necessary to prepare our code to not depend on Fibers' sync code anymore. This led to the PR 28929 that was later replaced by the PR 29112, where we changed hundreds of files and incorporated external libraries to convert all the Fibers code to async code. Fortunately, most of those changes were able to be merged into our current releases since we "demeteorized" a good part of our application, versions 6.1 and 6.2 incorporated most of our refactors, including a good amount of files converted from JavaScript to TypeScript to facilitate the async conversion and ensure quality.
On May 10, we finished our efforts, ten days after the NodeJS 14 End of Life. We started to test with the current Meteor 3 development code and later with their alpha releases. Unfortunately, Meteor was not ready to run without fibers then, so we started contributing the framework to make progress as fast as possible. We are still in this phase now, waiting and helping Meteor to have version 3 without fibers and running NodeJS 18 to be able to release a version of Rocket.Chat capable of running a supported NodeJS version.
Since June 22, our changes to the upgrade are passing all of our tests on our CI running Meteor 3.0 Alpha.10. It's still running on NodeJS 14, but it's not depending on Fibers at all. We are waiting on Meteor for the next Alpha release, which should bring NodeJS 18.
So what happens if a security issue is found before the upgrade is released?
Meteor announced an extended support window for NodeJS 14 a year. It means that Meteor organization will maintain a fork release of the NodeJS and backport or fix any found issue during this period. Of course, it's not the ideal scenario since it requires users to install NodeJS from a fork, but it's still a good alternative if necessary.
We are currently in touch with the Meteor team to follow up and help as much as possible to make this happen ASAP and not depend on the forked NodeJS alternative anymore.
We will keep everyone updated on this thread once we have new chapters.
Beta Was this translation helpful? Give feedback.
All reactions