How are you deploying to production? Did you mean that you are running the meteor tool in production (with the bundled node version)?
We do not run “meteor” nor the “bundled node version” in production. But our custom AMI uses the meteor team’s forked node version. Some folks might be ok with the provided AMI by AWS
AFAIR the problem with deploying Meteor 2.15 on a Node 20 machine in EBS was related to Python and the compilation of/by pre-gyp/node-gyp which I think is used/necessary by bcrypt.
Can someone confirm this “warning” in the migration document?
TIP
It is not recommended to use concurrent calls. Use await for your Meteor.callAsync.
Previously, this was only the case if you have stubs. It seems that the “stubs qualifier” is no longer applicable based on the current migration document
You can still use Meteor.call if you know what you’re doing (not using it with stubs as you mentioned). We recommend that you use Meteor.callAsync because you won’t need to think about stubs when calling a method, and it will prevent weird behavior.
@denyhs, I am referring to Meteor.callAsync() in this case. The migration document I linked above mentioned not to use it concurrently.
Then there is this example:
// it is not recommended to use concurrent calls
Promise.all([ // This is not ok
Meteor.callAsync('someMethod'),
Meteor.callAsync('someMethod')
]).then(([data1, data2]) => {
console.log(data1, data2);
});
I really like the proactive communication form that’s taking place from the Meteor team, showing current and future plans along with past achievements. Please keep them coming
So far we have released rc4 as we mentioned in our previous updates, and work is progressing well for our official Meteor 3 release.
You can check here for more details about our last Release Candidate.
The backlog has evolved a little over the last days with some issues gaining priority, our most important ones are as follows:
Incorrect Node.js version in Meteor project if the meteor-tool is missing, this has gone up in priority but it’s extremely hard to solve, we have a path forward but have some loose ends we need to account for, some tests on Windows are failing at the moment
The method call order when Meteor goes back from offline and authentication
Finding a replacement for @vlasky/whomst since it depends on a package called posix which builds a binary and breaks on some installations
We also confirmed that Cordova is working completely fine, this was done by @nachocodoner, one of our developers with the most expertise in that area.
We are also revamping the documentation and researching ways to simplify the mechanics for call and callAsync, we have @denyhs at this forefront and also huge help from @zodern . The goal is to make Meteor have the best Developer Experience as possible and the migration as simple as possible too.
Other tasks and fixes for the next, and official, Meteor 3.0 Release:
Unable to run bundle from “meteor build”
Ensure the documentation is up to date
Upgrade Node.js to v20.14
Improve package version resolution process
React Router SSR for Meteor 3
Remove pinned version of packages inside the skeletons
Add addEmailAsync alias
Incorrect Node.js version in Meteor 3 projects
Review Security Updates
Rename or remove asyncLocalStorage global
Verify tinytest major version increase
Meteor 3.0 is expected to arrive on Monday, July 8th or 15th at the most
Next Releases
Meteor 3.0.1 (July 22nd, 2024)
Meteor 3.0.2 (August 5th, 2024)
These dates are subject to change as we add or remove things from the backlog.