The link copy suggests that this has not been successfully migrated to npm 9 (“Right now we have Meteor at version 3.0-alpha.11 with Node 18 and Npm 8”). Does that need to be updated or is it correct?
I think the task status is done is what @denyhs wanted to highlight with the link.
Great work folks, really excited for this.
1 Like
ah! Got it 
So focused on copy I did not notice the status checkmark.
1 Like
At the moment, we have the latest alpha with Node 18 and Npm 8
We just finished the update to npm 9, and we will release a new alpha version to include these changes.
6 Likes
Thanks for clearing it up. I’m trying to figure out what to report this week on MeteorJS Dispatches. That is, looking for what the build will be that they can download. Expecting 3.0-alpha.13 or something similar…
I appreciate all the work that everyone in the core team is doing to handle the release of Meteor 3.0. At the same time, I love the loyalty and commited community based on the love for the tool. The open to speech and proactive spirit define us on our endevors to keep using Meteor in our daily basis, whether it’s in the form of personal usage or through invaluable contributions such as packages and enhancements. We should not lose the focus on that no matter which are the circumstances and reactions around us.
I am excited and motivated on Meteor 3. I started to use it locally. In fact, I wish go further and start provinding some adaption to community packages, to not use fibers anymore.
I created a small app using Meteor 3, and I realized that tests are not working properly. We are missing the adaption of test packages there. Tests are an essential part to adapt the rest of packages, since almost all them involve to run tests to verify the behaviors are still working.
I did some changes on test packages to be fiber-free and I was able to pass properly the tests for an example app as you can see in the picture below.
I am not sure if it will cover all scenarios. Surely, there is more to adapt, like test coverage and may others, this is just a start. But the simple test capability may be adapted with a minor change I could commit for review.
My questions are:
- Is anyone already in charge of the testing part? Is it planned or already tackled by the core or any community member?
- How would the procedure be to start contributing with the changes on the packages?
I believe these are the next steps to define in order to get more people involved on this migration.
8 Likes
It is part of the Beta Roadmap: Fibers Public Roadmap - Meteor 3.0 · GitHub
@hschmaiske might give a better answer on this
As rjdavid said, it’s part of the roadmap, but you could definitely help.
Even if you don’t have everything ready right away, you can open a draft PR against this branch with a detailed description of what you’re doing and a checklist of what’s missing.
If you need any help, you can also DM me on Slack.
2 Likes
Hello everyone, quick bi-weekly update:
Here are the latest updates on the successfully completed tasks:
- New alpha version - You can create a new app with this version by running
meteor create --release 3.0-alpha.15 myapp - Review major/minor version of packages - we reviewed all the packages and rolled back the versions that didn’t need to be updated.
Currently, we are actively working on the following tasks:
- Fix problems with our tutorials when doing them with Meteor 3 - we’re extensively testing our Alpha version right now to make sure we can refine it more before a Beta version. We already found simple bugs, like
Cursor.count()not working properly. So we want to tackle those types of bugs first before releasing a Beta. - More will be started in the next few days
You can follow the updates on our Fibers Public Roadmap and on this Github PR
13 Likes
I heard that in Meteor 3.0, we will use express server and remove connect package. Is that right?
That’s right @minhna! If you have any concerns, there is a topic with some discussion around it.
2 Likes
Hello everyone! Here is a small update:
Some tasks we’ve been working on it:
- Fix problems with our tutorials when doing them with Meteor 3: We worked on this from different PRs: #12802, #12808.
- Unhandled Rejection when fails to bundle the app: We found this problem while working on the above issue. It goes deeper than we thought, and we continue to investigate the root of this problem.
Our plan for the next week is to release one more Alpha, which will include changes like this one and this one.
After that, we’ll address the issue Unhandled Rejection when fails to bundle the app as well as more issues our community is reporting, like this one.
See you soon for more updates!
You can follow the updates on our Fibers Public Roadmap and on this Github PR .
10 Likes
Hi everyone! First of all, I want to say thanks for the effort updating Meteor to V3 which is a huge change and we really appreciate.
Currently we’re using Meteor v2.13.3, and lot’s of libraries are forcing us to update to node >= 16 at least, and I’m really worry about this, because our apps are getting outdated since we can’t safely upgrade our libraries. And I think that use meteor 3.0-alpha.17 on production is discouraged since it’s just an alpha version.
I can’t see any deadline for a stable Meteor v3 release. Do you have any deadline on mind?
Do you have any suggestion for people that want to use a more recent Node version and minimize the errors on production?
Thanks for your time!
5 Likes
While that’s something only the core team can give you a definitive answer. You can follow the progress of 3.0 migration by following this thread and the official project board on GH.
Also, since you’re on 2.13.3 you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already out and provide feedback for the core team.
1 Like
Hi Harry! Thanks for your reply.
You can follow the progress of 3.0 migration by following this thread and the official project board on GH.
I was already checking it since a few months, but it doesn’t help me to estimate if it will take 4 months, 6 months or even more to have a stable production version, and all other libraries are pushing us to upgrade in the meantime since we’re running on outdated versions.
you should not wait for 3.0 to be officially released to start working you can already start migrating your applications today as the alpha is already
I know that I should not wait for 3.0 to be officially released to start working on the migration of our applications, but we can’t launch an alpha version into production.
Anyway, sorry if it sounds rude at some point, I really appreciate the whole work that team is doing.
This comment has two main ideas:
- Let the community know that we’re also worry about this, because it’s something critical stay using an unmaintained Node version on production.
- See if somebody has a good recommendation or workaround for us.
It’s cool. I know I’m stating the obvious but it’s the best I can do until a core member jumps in 
2 Likes
What @harry97 is speaking here about is migrating to the new *Async function calls. You can push those already into production with your existing 2.x Meteor app. They are there for forward compatibility. This way you can migrate your app’s methods step by step and then when the time comes for 3.0 upgrade you will have only minimum work on the remaining API changes.
Thanks for your reply @storyteller!
Let me see if I understood correctly. So what you say is that is safe release our app without any change with meteor 3.0-alpha.17, since it’s retro compatible, and therefore we will be able to use a more recent Node version on Meteor without breaking anything.
Did I get you correctly?
No. Implementing the new Async calls will not make it possible to run on newer Node versions right now. Newer Node versions require Meteor to not use Fibers anymore and this is done in Meteor 3. What those Async call allow you to do is to execute some of the migration work right now while you are on Meteor 2.13, so that when a stable version of Meteor 3 ships you’ll have less work to do. At least that seems to be the plan.
This isn’t easy. In one project, we have around 20 npm packages that cannot be updated because of node 14. For a few packages with severe security issues, we were able to find alternatives. But tracking becomes a lot more difficult when the dependencies of those packages are the ones with security updates.